Simon Marlow writes:

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.

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.