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
--
Derek Upham
s...@blarg.net
