On Sun, Feb 24, 2013 at 2:31 PM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been experimenting with an alternative implementation of<br>
'System.Timeout.timeout'[1] which avoids the overhead of spawning a new<br>
thread for each invocation.<br>
<br>
Part of my motivation is to see if I can implement a faster version of<br>
<br>
threadWaitReadTimeout :: Int -> Fd -> IO Bool<br>
threadWaitReadTimeout to = liftM (maybe False (const True))<br>
. timeout to . threadWaitRead<br>
<br>
and thus exploit GHC's event notification system instead of having to<br>
reimplement a timeout-manager myself (like popular HTTP server libraries<br>
such as Snap or Warp do currently).<br>
<br>
<br>
The following Haskell program shows a proof-of-concept implementation<br>
derived directly from 'System.Timeout.timeout' together with a Criterion<br>
benchmark comparing the performance between the original and the<br>
alternative 'timeout' function wrapping a 'readMVar' call.<br>
<br>
<br><br>
On a i7-3770 with GHC-7.6.2/Linux/64bit ran with "+RTS -A4m -N4", the<br>
benchmark shows a 15x improvement for the new implementation (below 1<br>
uS) compared to the original implementation (~13 uS):<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>-- Johan</div><div><br></div></div>