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

[Eli Zaretskii]

> From: Mark H Weaver <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden (Ludovic Courtès), 
> address@hidden
> 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?