[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) |
Greets!
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.
> <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/