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

[Volker Stolz]

In local.glasgow-haskell-users, you wrote:
> 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?

That's what I thought, too, but then it turned out to be a real
hassle to rewrite the entire application to synchronise on a
specific location. I'm also quite sure that this would introduce
accidental deadlocks for non-trivial concurrent systems.

Assume you have some kind of asynchronous database running in a
separate thread, listening on a channel for requests. Now you have
to introduce a construct which not only waits (suspends) on the 
channel, but even on another MVar (or add a new "command" for shut
down). I tried this, but it really turned out to be much more
overhead, especially in terms of maintainability of the source-code.
Granted, from the software-engineering point of few, it is much
cleaner, but on the other hand, you have the already existing
semantics of fork() in a pthread which does exactly the same: Only
fork the current thread and not the others.

I was toying with two functions called freezeThread and thawThread
which would allow you to selectively halt and resume threads, but
even the Java-guys dropped that from their specs because of the
potential havoc you could cause.
-- 
plonk :: m a -> m ()
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME