Re: Why launch the Guile signal delivery thread on exit? (was Re: guile 2.0.9 build on mingw)

[Eli Zaretskii <eliz@gnu.org>]

> From: Mark H Weaver <mhw@netris.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, ludo@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?