> Threaded RTS improvements: > > - Unix only: implement waitRead#, waitWrite# and delay# in Haskell, > by having a single Haskell thread (the IO manager) performing a > blocking select() operation.
Yippie! > Signals aren't quite right in the threaded RTS. In fact, they're > slightly worse than before, because the thread receiving signals might > be blocked in a C call - previously there always be another thread > stuck in awaitEvent() that would notice the signal, but that's not > true now. I can't see an easy fix yet. 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. Cheers, Wolfgang -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ _______________________________________________ Cvs-libraries mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-libraries
