> *) 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).
Correct. I think this is a hangup from the days before thread-friendly
signal handling, and I didn't think too hard about it when converting
the code.
> *) 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?
I like the second option. In fact, I'd like to use the same mechanism
to handle SIGCHLD in the RTS so we can do thread-friendly waiting in the
non-threaded RTS as per discussion on the libraries list recently.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
