> From: Mark H Weaver <m...@netris.org>
> Cc: Eli Zaretskii <e...@gnu.org>, l...@gnu.org (Ludovic Courtès),
> guile-user@gnu.org
> Date: Tue, 18 Jun 2013 17:51:38 -0400
>
> The signal delivery thread is not launched until the first signal
> handler is installed. This would seem sensible if not for the fact that
> it is always launched at exit, which I found surprising.
Since launching a signal delivery thread hangs even if it happens
early in the program run, like as result of
(sigaction SIGINT)
I looked closer at what happens when that thread starts. What I found
is this:
- scm_spawn_thread calls scm_i_pthread_create
- a new thread is created running the spawn_thread function, and
GDB announces the new thread
- spawn_thread calls scm_i_pthread_detach, which calls
pthread_detach, which in turn calls pthread_mutex_lock, which
hangs inside WaitForSingleObjectEx
- scm_spawn_thread waits inside scm_i_scm_pthread_cond_wait for
the thread to release the conditional variable, which never
happens. So guile waits forever, a.k.a. "hangs".
According to this part of pthread_detach:
if (result == 0)
{
/* Thread is joinable */
if (destroyIt)
{
/* The thread has exited or is exiting but has not been joined or
* detached. Need to wait in case it's still exiting.
*/
(void) WaitForSingleObject(tp->threadH, INFINITE);
ptw32_threadDestroy (thread);
}
}
it seems like pthreads thinks that the thread has exited or is
exiting. But if the thread really exited, for whatever reasons, why
doesn't WaitForSingleObject return?
Does this ring a bell for someone?
