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