The edge-triggered misunderstanding

Posted Aug 10, 2021 2:13 UTC (Tue) by HenrikH (subscriber, #31152)
In reply to: The edge-triggered misunderstanding by wtarreau
Parent article: The edge-triggered misunderstanding

If you use it that way they you are leaving behind a larger and larger watch list for epoll. EPOLLONESHOT does not call EPOLL_CTL_DEL automatically for you, it simply marks the fd on the watch list as temporarily disabled after it wakes up.

It can be used for the scenario that you described but you have to do a manual call to EPOLL_CTL_DEL to really remove the fd from the internal watchlist and remove a potential memory leak.

The edge-triggered misunderstanding

Posted Aug 10, 2021 4:08 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (1 responses)

> EPOLLONESHOT does not call EPOLL_CTL_DEL automatically for you, it simply marks the fd on the watch list as temporarily disabled after it wakes up.

From the epoll(7) man page: "When the EPOLLONESHOT flag is specified, it is the caller's responsibility to rearm the file descriptor using epoll_ctl(2) with EPOLL_CTL_MOD".

You can use it for example to wait for a connect() to complete without having to disable polling on the FD when you don't intend to use the connection immediately (e.g. when preparing connection pools).

The edge-triggered misunderstanding

Posted Aug 10, 2021 16:50 UTC (Tue) by HenrikH (subscriber, #31152) [Link]

Yes, that goes exactly into what I was saying. Re-arming it resets the disabled flag in the internal watchlist. That you have to do this with EPOLL_CTL_MOD and not EPOLL_CTL_ADD should already there tell you that EPOLLONESHOT does not call EPOLL_CTL_DEL automatically.

So if you use this flag as a way to not have to call EPOLL_CTL_DEL then you have a memory leak (as well as an inefficient watchlist in epoll).

Not really sure where you are going with this since non of this contradicts what I have written now several times.