darcs patch: forkChild, waitForChild, parIO, timeout

[Peter Simons]

Einar Karttunen writes:

 >> +	forkChild,		-- :: Monoid a => IO a -> IO (Child a)
 >> +	activeChild,		-- :: Child a -> IO Bool
 >> +	waitForChild,		-- :: Child a -> IO a
 >
 > This makes it hard to have a manager thread that sits over a
 > pool of children and watches them.

I don't feel qualified to make an ad hoc judgment about that
assertion. I see no reason why these functions would make it hard
to implement a thread pool, but that doesn't mean there wouldn't
be one. Could you please elaborate your point a little bit? Do
you have a suggestion how the API can be improved?

Personally, my interest is in parIO and, by extension, in
timeout. I'd be perfectly happy to not export the "Child"
functions as long the base libraries provide some equivalent of
the latter two. I feel, however, that there are strong
indications that a paradigm like asynchronous computation of a
value is useful.


 >> +	-- ** Timeouts
 >> +	Timeout,		-- Timeout = Int
 >
 > Better have a type like MicroSecond or Second that conveys
 > the meaning.

Yes, that is a good idea. I'll submit an improved patch ASAP.


 >> +	timeout,		-- :: Timeout -> IO a -> IO (Maybe a)
 >
 > The implementation is actually non-optimal [...].

I don't think it's very important how exactly timeout is
implemented. As long as we can agree on that type signature, the
implementation can change as GHC evolves.

However, my experience is that the implementation I submitted
works just fine. I don't think it is obvious that your
implementation has better performance. One might argue that the
cost for setting up an asynchronous exception handler is (at
least) as high as the cost of forkIO, but I don't really know. In
any case, my guess is that the actual performance difference is
negligible for all practical purposes.

Peter