Re: Cygwin port of Guile 2.2

[zv]

On 05/02/2017 08:18 PM, Derek Upham wrote:
> Andy Wingo <address@hidden> writes:
> 
>> On Mon 01 May 2017 22:48, Derek Upham <address@hidden> 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)