Race-condition in alternative 'System.Timeout.timeout' implementation
bertram.felgenhauer at googlemail.com
Mon Feb 25 10:27:31 CET 2013
> I've been experimenting with an alternative implementation of
> 'System.Timeout.timeout' which avoids the overhead of spawning a new
> thread for each invocation.
Be warned that timeouts are very intricate. We had a lengthy discussion
on the topic 2 years ago, starting at
There was even an IO manager based proposal similar to yours:
(What's the busyWontTimeout benchmark mentioned there?)
The main trouble with the IO manager based approach is that even
after unregisterTimeout finished, the timeout may still be invoked,
and additional work is needed to protect against that.
(I have more to say on this, but will postpone it until later. A lot
of it has already been said in the earlier thread anyway.)
More information about the Glasgow-haskell-users