Re: Signal thread

[Andy Wingo <wingo@pobox.com>]

Greets!

On Tue 28 Jun 2011 18:46, ludo@gnu.org (Ludovic Courtès) writes:

>   2007-10-20  Julian Graham  <joolean@gmail.com>
>
>           Add support for thread cancellation and user-defined thread
>           cleanup handlers.  Small rework by Ludovic Courtès.

Ah, right.  I suppose it's disrespectful to have a moment of silence for
CVS, given that people still use it, but I don't miss its inability to
distinguish authors from committers.

> <http://lists.gnu.org/archive/html/guile-devel/2007-10/msg00029.html>:
>
>   * 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.
>
> At first sight it still holds.
>
> I checked on ‘stable-2.0’ by applying
> 3b971a59b55586a236c3621a55515d9272ee5c80 and then running threads.test
> under Helgrind, which didn’t report any lock order issue.  It could mean
> that I was lucky, though.

Currently scm_cancel_thread is called without any locks held, so there
should be no issues there.

We might have other locking order problems -- do_thread_exit takes the
admin lock and then the lock of a fat mutex, whereas fat_mutex_lock does
the other way around.  (Yuk, fat mutexes.)  Perhaps not, though.

Cheers,

Andy
-- 
http://wingolog.org/