A major problem with sd-event as an epoll replacement lies in how it handles multi-threading: It doesn't. The most error-prone part of using epoll in a multi-t

A major problem with sd-event as an epoll replacement lies in how it handles multi-threading: It doesn't. The most error-prone part of using epoll in a multi-threaded environment is free-ing of the per-descriptor state. You never quite know when the last epoll_wait that still knew about that descriptor has fired. There are multiple approaches for dealing with this problem, including RCU-like waiting for each thread to pass epoll_wait once, recycling descriptor states by including an anti-race generation counter in the unused bits of the event user data, or garbage collection. In contrast, with IOCP or other completion-based programming models, you can reference count the active I/O operations and free once the count reaches zero.