[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Signal thread

From: Andy Wingo
Subject: Re: Signal thread
Date: Tue, 28 Jun 2011 21:52:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)


On Tue 28 Jun 2011 18:46, address@hidden (Ludovic Courtès) writes:

>   2007-10-20  Julian Graham  <address@hidden>
>           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.

> <>:
>   * 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]