[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops

[GHC]

#8733: I/O manager causes unnecessary syscalls in send/recv loops
-------------------------------------+------------------------------------
        Reporter:  tibbe             |            Owner:  simonmar
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Runtime System    |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------
Description changed by tibbe:

Old description:

> Network applications often call send followed by recv, to send a message
> and then read an answer. This causes syscall traces like this one:
>
> {{{
> recvfrom(13, )                -- Haskell thread A
> sendto(13, )                  -- Haskell thread A
> recvfrom(13, ) = -1 EAGAIN    -- Haskell thread A
> epoll_ctl(3, )                -- Haskell thread A (a job for the IO
> manager)
> recvfrom(14, )                -- Haskell thread B
> sendto(14, )                  -- Haskell thread B
> recvfrom(14, ) = -1 EAGAIN    -- Haskell thread B
> epoll_ctl(3, )                -- Haskell thread B (a job for the IO
> manager)
> }}}
>
> The recvfrom call always fails, as the response from the partner we're
> communicating with won't be available right after we send the request.
>
> We ought to consider descheduling the thread as soon as sending is
> "done". The hard part is to figure out when that is.
>
> See http://www.yesodweb.com/blog/2014/02/new-warp for a real world
> example.

New description:

 Network applications often call `send` followed by `recv`, to send a
 message and then read an answer. This causes syscall traces like this one:

 {{{
 recvfrom(13, )                -- Haskell thread A
 sendto(13, )                  -- Haskell thread A
 recvfrom(13, ) = -1 EAGAIN    -- Haskell thread A
 epoll_ctl(3, )                -- Haskell thread A (a job for the IO
 manager)
 recvfrom(14, )                -- Haskell thread B
 sendto(14, )                  -- Haskell thread B
 recvfrom(14, ) = -1 EAGAIN    -- Haskell thread B
 epoll_ctl(3, )                -- Haskell thread B (a job for the IO
 manager)
 }}}

 The `recvfrom` call always fails, as the response from the partner we're
 communicating with won't be available right after we send the request.

 We ought to consider descheduling the thread as soon as sending is "done".
 The hard part is to figure out when that is.

 See http://www.yesodweb.com/blog/2014/02/new-warp for a real world
 example.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8733#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler