Proposal: System.Timeout module for base

[Simon Marlow]

Peter Simons wrote:
> Simon Marlow writes:
> 
>  > Any other suggestions?
> 
> The fact that blocking FFI threads cannot be timed out with the
> current implementation is unpleasant, and I would be happy to
> lift that limitation.
> 
> I wonder, though, whether depending on unportable low-level OS
> mechanisms like pthread_cancel() or pthread signals to deliver a
> timeout might prove to be far more unpleasant than the limitation
> we try to lift. As far as I'm concerned, the limitation that
> blocking FFI threads cannot be timed out from Haskell is not that
> hard. A blocking FFI call, well, blocks. In all honesty, I
> wouldn't expect that to be any different. I would be far more
> surprised if it turned out that my currently running C code
> suddenly receives signals and is supposed to deal with that.

Yes, agreed.

> My preferred approach would be to agree on the _signature_ of the
> combinator. We should find consensus that timeout is supposed to
> look like this:
> 
>   timeout :: Int -> IO a -> IO (Maybe a)
> 
> If that is the case, then we can add the function into the
> distribution now and worry about wild improvements of the
> implementation later. I feel that making even an unperfect
> solution available to Haskell programmers would be a significant
> step forward.

I'd go with the proposed signature above.

One further suggestion: the docs should mention *how* the timeout is implemented 
(namely as an asynchronous dynamic exception), which makes it clear that you can 
take the usual protective measures against mutable data getting into an 
inconsistent state when the timeout happens: exception handlers, bracket, 
withMVar, block/unblock etc.

Cheers,
	Simon