@monsieuricon Honestly, I just thought "Optimus-Prime's Slavic Brother"...

@jann @lcamtuf btw, @albcr sent patches to let process_vm_{read,write}v() work via pidfds. I think that's in -next.

@jann @muvlon Funny you say that as I looked at that just a few weeks ago. So the problem with O_NOTIFICATION_PIPE is that it's inhernetly fixed length and it has no support for event coalescing (if we ever needed that) nor does it allow to recover events easily. Plus I liked the idea of having the ability to use a uniform monitoring interface for general fs events and pidfd events. Plus with Amir and Jan it has very active and responsive maintainers with long-term plans.

@jann @muvlon Because poll() is just super limited in terms of how fine-grained it can communicate events and because it cannot actually send metadata as part of an event.

@jann @muvlon Note, that I think all of these cases could be handled a lot more elegantly if we finally enable pidfs integration with fsnotify() - which gets extended with custom event spaces. This would be pidfd monitoring on steroids.

@jann @muvlon
But this is difficult to handle because a thread-group may exit premature as mentioned in (2). In that case an exit notification is reliably generated but the subthreads may continue to run for an indeterminate amount of time and thus also may exec at some point.