Wolfgang Thaller wrote:
Thu Feb 9 04:30:56 PST 2006 Simon Marlow <[EMAIL PROTECTED]>
* improvement to the deadlock detection
When the RTS is idle, as detected by the timer signal, instead of
prodding capabilities from the signal handler (which is not guaranteed
to work - pthread_cond_signal() can't be called from signal handlers),
create a new thread to do it.
M ./ghc/rts/Timer.c -6 +22
I am pretty convinced that pthread_create has a lower chance of working
than pthread_cond_signal, as pthread_create has to allocate memory,
which is absolutely taboo in signal headers.
>
A library function that accesses a data structure that is also used by
the thread that is interrupted by signal will fail, either because it
observes an inconsistent state of the data (for non-thread-safe
libraries), or because it deadlocks waiting for the interrupted thread
to release a lock.
What about using our good old pipe to the IO manager?
Indeed, I thought creating a thread might be dodgy, but it did improve
things here (eg. try conc033 with -threaded).
Using the IO manager pipe is a good idea, but not foolproof: the IO
manager thread might not even be running, and the pipe might not have
been created yet - this is the case in conc033. Perhaps the runtime
should always ensure the IO manager thread is running before doing anything.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
