|
|
|
|
|
|
by nobodyandproud
536 days ago
|
|
|
Thanks. Then it seems like there are more similarities than differences here: Both solve the same problem
of “select” by being the central (kernel-level) events queue; though with different APIs. The other bit that caught my eye was the author saying epoll can do nearly everything kqueue can do. What is that slight bit that epoll can’t do? |
|
|
For instance, FreeBSD (and I think other BSDs) also have EVFILT_PROC, which lets you monitor a PID (not an fd) for events. One such event is NOTE_FORK, i.e., the monitored process just forked. Can you wait for such events with epoll? I'm not sure.
More generally, suppose you wanted to automatically start watching all descendants of the process for events as well. If I was required to use a separate fd to monitor that child process, then upon getting the fork event I'd have to somehow obtain an fd for that child process and then tell epoll about it, and in that window I may have missed the child process forking off a grandchild.
I'm not sure how to solve this kind of problem in the epoll world. I guess you could introduce a new fd type which represents a process and all of its descendants, and define some semantics for how epoll reports events on that fd type. In FreeBSD we can just have a dedicated EVFILT_PROC filter, no need for a new fd type. I'm not really sure whether that's better or worse.