On Wed, 2003-10-08 at 22:02, John Meacham wrote:
I was curious if there was a version of System.system floating about which doesn't block all threads when doing concurrency? just doing an actual fork and exec isn't sufficient because I need to do haskell things (like write to MVars) after the spawned app finishes.
I imagine this might be written by catching sigCHLD and writing to an mvar, but I can't seem to get at the siginfo_t structure from the haskell signal callback to find out the pid of the process which died.
Yes, it's annoying. I wanted to get that struct to get the file descriptor from notifications on completed async io operations. You can look in the ghc code that sets up and catches signals, it's not that complicated. The ghc signal handler basically uses a fixed length queue to store the signal number. Then in the scheduler it checks if any signals were received and if so, spawns a thread to handle each one. (This is just from a quick reading of the code, I'm not a ghc expert) I guess it could be altered to hold the whole siginfo_t rather than just the signal number but it'd take much more space. The whole thing is a bit unsatisfactory, if you don't use a dynamically growing queue (which is a bit tricky since you can't malloc inside a signal handler) then you just have to pick some arbitrary length of queue. If you get more signals than your queue length within a scheduler timeslice then the signals just get discarded. I've seen one technique where you write() into a pipe in non-blocking mode inside your signal handler. I don't know if that's kosher or not. That has the advantage that you get a dynamically sized queue, up to a maximum of 4k or so. That would easily be enough space in which to save the siginfo_t's. Another possibility is to use synchronous signal handling where signals get queued to a file descriptor which you can select()/poll() on. This is non-portable however (linux 2.6 or later only). Duncan