On 14 October 2004 16:24, Wolfgang Thaller wrote:
> What about using a pipe to send signal information (maybe the whole
> siginfo_t) to the IO manager, and have the IO manager start any
> Haskell signal handlers?
> Pipes are the only synchronization mechanism that's guaranteed to work
> from signal handlers anyway. We can't use pthread synchronisation (it
> works on some platforms, but is officially unsupported). The current
> practice of re-sending the signal to another thread using pthread_kill
> isn't perfect either; it breaks in the presence of third-party
> libraries that handle a signal and pass it on using raise() or kill()
> (so it no longer gets sent to a specific thread). Readline is one of
> those evil libraries.
>
> When too many signals arrive, we're out of luck with the pipe; what
> do we do when the pipe isn't emptied fast enough and the write to the
> pipe wants to block? So we should be careful not to write too much
> data to the pipe. The only other alternatives I can think of (apart
> from pipes) are a) using platform-specific atomic instructions to
> synchronise the signal handler to the rest of the RTS or b) ignoring
> countless warnings and using the pthread APIs from the signal
> handler. I can testify that Mac OS X's implementation of mutexes
> works from signal handlers (if you avoid the obvious deadlocks). But
> we'd still need a pipe to wake somebody else, so I vote for just
> using a pipe by itself.
Yes. I wanted to make the current handleSignalsInThisThread() solution
work for now, but couldn't see a way to do it. But you're right, using
a pipe seems to be the Right Thing. Especially since we already have a
pipe.
Installing a signal handler will need to ensure that the IO service
thread is running, BTW.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
