In D35155#799022, @pauamma_gundo.com wrote:

Manual page change is probably small enough to be fixed while committing if nothing else needs revision. (As always, I can't attest to source change or consistency between it and manual page.)

Thank you! Since I don't really understand the role of influx in kevent() I won't commit until Kostya criticizes kqueue_sccan changes

Is this Review still valid, valuable, and ready to land?

In D35155#944705, @editor_callfortesting.org wrote:

Is this Review still valid, valuable, and ready to land?

Please, see my previous comment, also it would be nice to test in the real environment

Reading the description of EPOLLEXCLUSIVE from the epoll_ctl manual page, this looks like it provides the wrong semantics. The use-case for EPOLLEXCLUSIVE seems to be that you have multiple epoll descriptors being used to monitor events on a single object; when an event occurs, only one of the epoll descriptors will receive the event. In the Linuxulator there is a 1-1 correspondence between kqueues and epoll descriptors. You are translating EPOLLEXCLUSIVE to a per-knote flag, and if N kqueues contain an event for a given resource, there will be N independent knotes. The tests work because they use a single kqueue, but I believe that epoll semantics require EV_EXCLUSIVE to work across multiple kqueues. I believe it is unusual to have multiple threads sharing a kqueue anyway; see https://www.usenix.org/system/files/atc21-zhao.pdf

So, I would expect an implementation of EPOLLEXCLUSIVE to, at least, modify knote() such that we avoid activating more than one knote with EV_EXCLUSIVE set.