Greets! On Tue 28 Jun 2011 18:46, l...@gnu.org (Ludovic Courtès) writes:
> 2007-10-20 Julian Graham <jool...@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/
