I've noticed two problems with GHC's current signal implementation.
*) What does the "maybe_mask" parameter to System.Posix.Signals.installHandler really do?
It sets the signal mask that will be in effect while generic_handler() in the GHC RTS executes. This is not what we want.
We want to set the signal mask for generic_handler appropriately so that one invocation of generic_handler can never be interrupted by another invocation of generic_handler. That means, on entry into generic_handler we have to disable _ALL_ signals that we have Haskell handlers for. Currently, it looks as if we have a race condition here (both in the threaded and non-threaded RTSs).
*) Readline is evil. If we send a signal using pthread_kill() to a specific thread, Readline catches it, and resends it to the whole process using kill().
This is very bad, because the threaded RTS uses pthread_kill to make sure that signals get handled by the right thread (the one that holds the Capability) to prevent race conditions; now if I press ^C in ghci + threaded RTS, I get an infinite loop (on platforms with POSIX-compliant signal handling, like Mac OS X and Linux with the new Native Posix Thread Library; it works perfectly with Linux's old LinuxThreads library).
I've already reported this to the Readline developers, but I haven't received an answer yet and I doubt they can fix this quickly without causing other problems (readline would have to link to libpthread). Anyway, a fixed version won't be in common use quickly.
Possible workarounds:
-) Don't use pthread_kill, but use pthread locking primitives to serialize signal handlers.
This seems to work (and makes the code simpler), the Mac OS X implementation of pthreads looks like it really works in all cases, but I found no documentation that defines the interaction between pthread_mutex_* and signals.
I'm not getting any deadlocks because I always block signals before acquiring the lock, but some pthreads implementations could do other evil things that might cause trouble (I can't think of any, but I'd prefer to have a guarantee).
-) Don't use pthread_kill, abolish the pending_handler_buf and use a pipe to send the information from the signal handelr to the scheduler loop. We could use the pipe we already use for waking a blocked worker thread.
Should be simple enough, and I read somewhere pipes are guaranteed to be usable from signal handlers.
Any opinions?
Cheers,
Wolfgang
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
