|
From: Doug R. <df...@nl...> - 2004-02-14 19:18:06
|
On Sat, 2004-02-14 at 18:45, Jeremy Fitzhardinge wrote: > On Sat, 2004-02-14 at 09:23, Doug Rabson wrote: > > I've been trying to sort out a problem found by one of the people > > testing the FreeBSD valgrind and it looks like a nice tricky one. They > > have one thread which blocks itself in pthread_cond_wait. Thats the > > first problem, valgrind immediately dies thinking there is a deadlock. I > > can 'fix' that by not panicing if all threads are stuck waiting on CVs. > > > > The next part of the test isn't so easy. The user issues a SIGINT (via > > ^C or similar) which is caught by a signal handler which calls > > pthread_cond_broadcast. This is supposed to allow the program to exit. > > Unfortunately, the broadcast is ignored because while the thread is in > > the signal handler it isn't in WaitCV state. > > > > Anyway, the testcase is attached for your amusement. > > I was wondering when people would try something insane like this. The > deadlock test isn't completely correct, because as you say, most > blocking functions can be interrupted by a signal (though is it OK to > use pthread_cond_broadcast in a signal handler?). > > >From the scheduler's perspective, it's hard to see how you can come up > with a sane notion of being both blocked in a CV and actually executing > instructions at the same time... Still, this behaviour works 'correctly' on FreeBSD, Linux, Solaris and probably most other pthreads implementations. This testcase is a distillation of how they get their application to shutdown cleanly. The main problem is that while it runs the signal handler, the thread isn't in WaitCV state (so the pthread_cond_broadcast doesn't do anything) but when the signal frame is popped, it goes right back to sleep. Somehow I need to be able to tweak the saved thread state in the signal frame (or something). |