Glasgow-haskell-users digest, Vol 1 #672 - 1 msg

[George Russell]

glasgow-haskell-users-request@haskell.org wrote:
[snip]
> I've been experimenting with making an asynchronous IO library. At the
> moment it uses Haskell threads but the idea is that it could be
> transparently extended to use system AIO.
I think what you are really asking for is asynchronous events, a la Reppy.
I don't like to blow my own trumpet (well, I do actually), but I've
already implemented these in Haskell, see the paper in ICFP 2001.  Of course
John Reppy got there first with PML/CML.
> 
> http://charlesstreet22.force9.co.uk/~duncan/projects/aio/AIO.hs
> 
> My question is if there is an effecient way to block / wait on multiple
> MVars. takeMVar & readMVar can wait on one MVar. The puspose is to be
> able get the reults of a list of AIO operations, in the order in which
> they complete.

Not at the moment.  Also I'm not sure such a thing could usefully be added
without more or less adding events anyway.  It's not enough to have

   takeOneMVar :: [MVar a] -> IO a

which looks for the next a, because pretty soon someone is going to want you to
implement

   data MVarActionPair a = forall b . MVarActionPair (MVar b) (b -> IO a)

   takeOneMVar' :: [MVarActionPair a]

This I suppose could be done without too much trouble, but then you run into problems
because the supplier of events has no way of knowing if these events are actually being
picked up or not, something that can be very important.  To solve this problem in general
you need Reppy-style higher-order events.  So you might as well have implemented those from 
the beginning anyway.

Also I am very much opposed to loading extra burdens onto the implementors of MVar's unless
we can be reasonably sure that MVars won't get slower as a result.  MVars are an excellent
low-level abstraction; it's better to build more complicated things on top of MVars as
required.


Good luck,

George Russell