[EMAIL PROTECTED] 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 _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
