#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): The approach you mention is actually what the IO manager pre 7.8 did, although it didn't have `threadWait{Read,Write}WithTimeout` methods, so you would have to code this via the lower-level interface in `GHC.Event`. In the 7.8 IO manager, the approach you describe won't quite work. The 7.8 manager uses a separate `poll` instance to handle timeouts (much as you described) and uses `epoll` instances (one per HEC) to monitor files. The reason that we don't handle timeouts in the epoll instances anymore is that the 7.8 manager uses non-blocking calls to `epoll`, and it sometimes yields and moves to the back of the run queue of its HEC. This often reduces the number of blocking foreign calls. But it means that `epoll` may not be called in a timely fashion, because it may wait for a bunch of busy Haskell threads on its HEC to finish. For that reason, we keep a separate Haskell thread monitoring a `poll` instance just for timeouts. In contrast, in the pre-7.8 IO manager, the IO manager thread always did a blocking `epoll` call, so it could use the earliest timeout as the timeout for the `epoll` call. It would then have to wait for at most one Haskell thread to finish after the foreign `epoll` call returns in order to grab the HEC and dispatch callbacks. Tighter integration of the IO manager and the scheduler might help here. With the integration, we may not need the trick of sending the IO manager to the end of the run queue. Then we could probably match the latency characteristics of the pre-7.8 manager (wait at most one Haskell thread to fire callbacks) and the throughput of the 7.8 manager. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler