0
votes

I have an application that, when it has data to transmit, uses epoll to know whether a given TCP socket can be written to.

What I'm observing is that as the far-end of the TCP connection falls behind, and the send buffer of the TCP socket begins to fill, the frequency with which epoll returns an EPOLLOUT event appears to experience exponential backoff. This behavior happens prior to receiving an EAGAIN from the socket write.

The application is using EPOLLONESHOT, and makes an EPOLL_CTL_MOD call to rearm the EPOLLOUT event after each occurrence. But as I noted above, each subsequent occurrence is exponentially later (I had a progression of 40ms, 80ms, 160ms, 320ms, 640ms, 1280ms, etc), up until EAGAIN finally happens.

Is this an undocumented feature of epoll? Can it be disabled? It's a problem because the data is getting stale and I would prefer to discard it rather than send it late.

Thanks in advance.

1
If stale data is a concern, use UDP not TCP; that's why the two protocols were invented. - msw

1 Answers

1
votes

No, but TCP does. epoll() blocks for at most the timeout you specify, and not a moment longer.