[Top][All Lists]

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

Re: Cygwin port of Guile 2.2

From: Derek Upham
Subject: Re: Cygwin port of Guile 2.2
Date: Tue, 02 May 2017 20:18:42 -0700
User-agent: mu4e 0.9.17; emacs 25.1.1

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

       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

       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 Upham

reply via email to

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