3 ms·

The BSD kqueue has similar problems, in a different event domain. The semantics of the interface and the mechanics of the data structures mean that an EVFILT_P

by JdeBP 8y ago

The BSD kqueue has similar problems, in a different event domain. The semantics of the interface and the mechanics of the data structures mean that an EVFILT_PROC event with NOTE_FORK will be overwritten by an EVFILT_PROC event with NOTE_EXIT for the same process, meaning that it is not possible to always correctly track the children of processes that fork and then rapidly exit, or of ones that rapidly fork multiple times. Fixing this would entail letting go of one of the architectural concepts of the system, either that a filter+ident pair uniquely identifies an event in a queue or that a process only ever has one event queue. (Letting go of the latter also entails a further mechanism for polling multiple event queues.)

wahern 8y ago
I think the issue, ultimately, is buffering. Kernel interfaces that can't preallocate space at request time are problematic. If you can allocate space sufficient to store the event(s) at the same time that you request notification, error handling is easy and obvious from a design perspective. Unbounded, asynchronous buffering in kernel space is simply a non-starter unless you don't care about consistency and reliability. Linux developers generally follow (coincidentally?) the GNU directive[1] of lazy, dynamic allocation, and it's why Linux interfaces can be so problematic and why everybody throws up their hands when one raises concerns about OOM handling. The reason EVFILT_VNODE works where inotify doesn't is precisely because EVFILT_VNODE requires an open file descriptor, which indirectly behaves as a preallocated buffer for storing pending events. But just like with signals, like events are coalesced and ordering can be lost. I think the most straight-forward solution to fork notifications is to block the forking process if the event can't be enqueued. That might be the only proper solution, period, if you want guaranteed delivery with the new PID. That creates the potential for deadlocking, but that already exists with other facilities like file locking, pipes, etc. [1] https://www.gnu.org/prep/standards/standards.html#index-arbitrary-limits-on-data https://www.gnu.org/prep/standards/standards.html#index-arbi...

by JdeBP 8y ago

wahern 8y ago

I think the issue, ultimately, is buffering. Kernel interfaces that can't preallocate space at request time are problematic. If you can allocate space sufficient to store the event(s) at the same time that you request notification, error handling is easy and obvious from a design perspective. Unbounded, asynchronous buffering in kernel space is simply a non-starter unless you don't care about consistency and reliability. Linux developers generally follow (coincidentally?) the GNU directive[1] of lazy, dynamic allocation, and it's why Linux interfaces can be so problematic and why everybody throws up their hands when one raises concerns about OOM handling. The reason EVFILT_VNODE works where inotify doesn't is precisely because EVFILT_VNODE requires an open file descriptor, which indirectly behaves as a preallocated buffer for storing pending events. But just like with signals, like events are coalesced and ordering can be lost. I think the most straight-forward solution to fork notifications is to block the forking process if the event can't be enqueued. That might be the only proper solution, period, if you want guaranteed delivery with the new PID. That creates the potential for deadlocking, but that already exists with other facilities like file locking, pipes, etc. [1] https://www.gnu.org/prep/standards/standards.html#index-arbitrary-limits-on-data https://www.gnu.org/prep/standards/standards.html#index-arbi...