GitLab

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.