Why it's dangerous to fork off a new process in Glasgow Haskell

[Alastair Reid]

> It would be good if there were a way of telling GHC's RTS scheduler
> "Please don't run any other threads apart from this one until
> further notice".

It seems like you're only worried about the threads which interact
with your servers.  A thread which continues printing prime numbers or
whatever to the screen probably wouldn't cause problems.

It also sounds like you want to be able to tell the RTS 'and if one of
the other threads is already talking to the servers, let it finish
first'.

In other words, it sounds like the right thing is to protect access to
the servers with some kind of lock (MVar, Semaphore, etc.).

Is there a reason why this won't work?

[I'm currently working on a system which lets you define your own
scheduler hierarchy.  Each scheduler has different consequences for
preemption and, hence, the kind of locks that its children may or may
not need to protect themselves from their siblings.  Reasoning about
which locks to use where is... challenging.  I'd be interested if your
program cannot be solved with a carefully placed lock but can be
solved with a novel scheduler hierarchy.  Not that it'd do _you_ any
good though - the scheduler hierarchy is for embedded systems which
tend not to be written in Haskell...]

--
Alastair Reid                 alastair@reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/