|
From: Jeremy F. <je...@go...> - 2004-02-14 18:47:54
|
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... J |