Claus Reinke wrote:
> Right. I am relieved to read that your application source is not
> full of calls to putMVar, but rather uses safe abstractions built
> on top of MVars (it might be interesting to isolate them out of
> your current application and migrate them to a CH library?).
Not a bad idea. Public implementations of channels are already available
(I believe there is already code provided with GHC.) I think Einar Karlsen's
composable events are an even neater idea and I should like to publicise and
extend them some more later on, maybe by writing a paper about them.
I don't understand the "tryButDoNotSuspend" operation. What does it mean,
"would lead to an immediate suspension of the current thread"?
It would incidentally be fairly trivial to implement tryForAWhileButDoNotBlockForever
using Einar Karlsen's events. (Except of course that delays are always going to
be approximate; GHC might not be able to run the thread bang on time because it
could be in the middle of some C function.)
I think the rest of Claus's discussion is a very good illustration of what I
said before that you can think of other primitives that could arguably be
provided for MVars and perhaps we should think the whole issue through
carefully. Another thing which MVars can't do very well at the moment
is multiple access. Perhaps there should be a function
takeMVarList :: [MVar a] -> IO a
which waits for the first MVar to come along. (Again, you could easily
implement such a thing using MVars defined in terms of Einar's events.)
Well I have no quarrel with orthogonal extensions to MVars PROVIDED THAT
THEY DO NOT GET SLOWER. So what do the wizards of GHC say can be done for free?
