return() versus pthread_exit() in pthread start functions

(1) In C++ code, using return causes the stack to be unwound and local variables destroyed, whereas pthread_exit is only guaranteed to invoke cancellation handlers registered with pthread_cancel_push(). On some systems this mechanism will also cause the destructors for C++ local variables to be called, but this is not guaranteed for portable code --- check your platform documentation.

Also, in main(), return will implicitly call exit(), and thus terminate the program, whereas pthread_exit() will merely terminate the thread, and the program will remain running until all threads have terminated or some thread calls exit(), abort() or another function that terminates the program.

(2) The use of return works because the POSIX specification says so. The returned value is stored in a place where pthread_join() can retrieve it. The resources used by the thread are not reclaimed until pthread_join() is called.

(3) I never use the return value of a thread in raw POSIX threads. However, I tend to use higher level facilities such as the Boost thread library, and more recently the C++0x thread library, which provide alternative means for transferring values between threads such as futures, which avoid the problems associated with memory management that you allude to.

I think that return from the start_routine is preferable, because it ensures that the call stack is properly unwound.

This is even more important for C than C++ since it doesn't have the destructor magic that cleans up the mess after preliminary exits. So your code should go through all final parts of routines on the call stack to do frees and alike.

For why this works, this is simple

If the start_routine returns, the effect shall be as if there was an implicit call to pthread_exit() using the return value of start_routine as the exit status

For my personal experience I tend to not use the status of terminated threads much. This is why I often have the threads started detached. But this should depend much on the application and is certainly not generalizable.