I've been experimenting with an alternative implementation of
'System.Timeout.timeout'[1] which avoids the overhead of spawning a new
thread for each invocation.

Part of my motivation is to see if I can implement a faster version of

threadWaitReadTimeout :: Int -> Fd -> IO Bool
threadWaitReadTimeout to = liftM (maybe False (const True))
. timeout to . threadWaitRead

and thus exploit GHC's event notification system instead of having to
reimplement a timeout-manager myself (like popular HTTP server libraries
such as Snap or Warp do currently).

The following Haskell program shows a proof-of-concept implementation
derived directly from 'System.Timeout.timeout' together with a Criterion
benchmark comparing the performance between the original and the
alternative 'timeout' function wrapping a 'readMVar' call.

On a i7-3770 with GHC-7.6.2/Linux/64bit ran with "+RTS -A4m -N4", the
benchmark shows a 15x improvement for the new implementation (below 1
uS) compared to the original implementation (~13 uS):

Fast timeouts is really important for real world web servers, which typically need one timeout per connection (e.g. to avoid slowloris DOS attacks). We should make sure timeouts are as cheap and fast as possible. This seems like a step in the right direction.

-- Johan