On 05/02/2017 08:18 PM, Derek Upham wrote: > Andy Wingo <wi...@pobox.com> writes: > >> On Mon 01 May 2017 22:48, Derek Upham <s...@blarg.net> writes: >> >>> Running pthread_join() on a thread only guarantees that the thread has >>> returned an exit value. >> >> Would you mind providing a reference please? It is not that I don't >> believe you but I think it's important to know whether this is a bug in >> Guile or in the pthreads implementation. > > It’s not explicit, but it’s heavily implied by the pthread_exit(3) man > page: > > 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). > > Any clean-up handlers established by pthread_cleanup_push(3) that > have not yet been popped, are popped (in the reverse of the order > in which they were pushed) and executed. If the thread has any > thread-specific data, then, after the clean-up handlers have been > executed, the corresponding destructor functions are called, in > an unspecified order. > > The retval becomes available to anyone joining. Then the clean-up > handlers run. Then the thread-specific destructors run. > > I think the flaw is that Guile is using the thread-specific destructors > to update global values. The thread is still effectively “live” (has > visible external effects) until the destructors finish running, even > though it appears to be dead if you were to ask pthreads about it. If > the destructor were just freeing heap memory (for example), then no one > would notice the delayed actions. > > Derek >
I believe Andy is spot-on here. I'm not familiar with a pthreads implementation where pthread_join() doesn't wait until the referenced tid is finished (unless you have reused a tid) (there may be a POSIX specification page dictating these sort of standards however)
