[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cygwin port of Guile 2.2

From: zv
Subject: Re: Cygwin port of Guile 2.2
Date: Wed, 3 May 2017 22:21:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]