0

First, I am new to pthreads, so if I completely misunderstood, please just let me know.

I had searched for the proper method of returning values and came across this link How to return a value from thread in C and https://linuxprograms.wordpress.com/category/pipes/ .

So I can share locations controlled by the starting thread OR pipe information, but the last value can't be put on some stack? Why can't I return in the same way that a program does when called by a shell (such as bash)?

(From what I understand, it would be possible to have a regular return value if it was C++, but (according to something I read I think here perhaps https://computing.llnl.gov/tutorials/pthreads/) POSIX isn't completely defined for C++, just C.)

Community
  • 1
  • 1
ConfusedStack
  • 251
  • 3
  • 13

2 Answers2

2

Take a look at pthread_exit and pthread_join.

When you are done with your thread you can call pthread_exit(void* retval)

The pthread_exit() function terminates the calling thread and returns a value via retval that (if the thread is joinable) is available to another thread in the same process that calls pthread_join(3).

This call to pthread_exit will stop your thread and, as it says, store the return value where pthread_join can get to it and place it in its second argument: int pthread_join(pthread_t thread, void **retval);

When you call pthread_join(tid, &returnVal); where tid is a pthread_t, returnVal will now hold a pointer to the value returned given to pthread_exit

This allows you to pass data out of threads on their exit.

Paul Rubel
  • 26,632
  • 7
  • 60
  • 80
  • 4
    `&retval` will similarly hold the value of the seemingly all-to-often-overlooked `void*` returned from the thread proc itself if `pthread_exit` is *not* invoked on the thread, choosing rather to simply let the thread-proc finish and `return something`. I prefer this approach, particularly when I have local-scope C++ objects that need destruction. – WhozCraig Feb 07 '14 at 18:15
1

Each thread has its own stack and local environment with the parent process. Your main process creates one thread (the main thread) and your code runs under it. Any other threads you create, get the same treatment: each gets a stack, a thread context, thread local storage (where applicable) and there is no common stack to return a value.

When you join a thread you started, what happens is you are actually waiting for it to finish executing. This will unblock the wait, but will not return any user value since typically, the thread, its stack, and all of its environment within the process is destroyed. While threads are running, they can communicate with one another in the ways you mentioned, and they can also read/write to common memory locations as long as you use a synchronization mechanism to serialize those accesses.

If you must have a return value from your thread, then you might want to encapsulate it in a class, pass it the class instance on start, then just before the thread exits, it can leave a "return value" in a member of this class so you can examine it after the class "run" or "start" method (the one that actually runs the thread) returns.

Hope this helps.

DNT
  • 2,356
  • 14
  • 16