While testing some of the changes I made for SRFI-18 support, I
noticed a couple of deadlocks in my thread cancellation code.  I've
updated my thread cancellation patch to address them.  Specifically:

* If a thread was interrupted by a cancellation while it was in Guile
mode (i.e., holding its heap mutex), a GC in another thread could
cause a deadlock by grabbing the thread admin mutex and then
attempting to seize the canceled thread's heap mutex -- the canceled
thread only releases its heap mutex once during cancellation (the heap
mutexes are recursive).  I've added a pthread cleanup handler to deal
with this case by releasing a thread's heap mutex before beginning the
exit procedure.

* If the signal delivery thread got launched a little bit too late, it
could be holding its startup mutex and then attempt to grab the
thread_admin_mutex, which could be held by a thread that was in the
process of being canceled and which was trying to obtain the signal
delivery thread's startup mutex.  I've resolved this by forcing the
signal delivery thread to start (if it hasn't already) during thread
cancellation of any thread.

Find attached a new version of the thread cancellation patch.


Regards,
Julian