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