non blocking System.system?

[Duncan Coutts]

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