Re: Kqueues and fork

On Wed, Aug 20, 2025 at 02:11:44PM +0300, Konstantin Belousov wrote:
> Right now, kqueues fds are marked as not D_PASSABLE, which means that
> the corresponding file descriptor is not copied into the child filedesc
> table on fork. The reasoning is that kqueues work on file descriptors,
> and not even files, so they are tied to the fdesc table.
> 
> As a curious coincidence, I have two private discussions last week,
> where in both cases people were interested in getting more useful
> behavior on fork from kqueues. [My understanding is that epoll does
> that, so there is a desire to make kqueue equal in the capability.]
> 
> I convinced myself, that indeed kqueues can be copied on fork.
> Precisely, the proposed semantics is the following:
> - fdesc copy would allocate a new kqueue as the same fd as the existing
>   kqueue in the source fdesc
> - each registered event in the source kqueue is copied into same event
>   (for the same filter, of course) into the new kqueue
> - if the event is active at the time of copy, its copy is activated
>   as well
> 
> The prototype in https://reviews.freebsd.org/D52045 gives the naive
> implementation of the idea.  What I mean by 'naive' is explained in the
> review summary, where I point out the places requiring (much) more work.
> 
> The new copy behavior is requested by the KQUEUE_CPONFORK flag to
> kqueue1(2).  Existing code that does not specify the flag, gets the old
> (drop) action on fork.
> 
> Example of the usage is provided by https://reviews.freebsd.org/P665.
> 
> Before I spend a lot of efforts into finishing this, I want to discuss
> the proposal:
> 
> Is this what the app writers want?

Looking at your patch, it seems that the child will receive a completely
separate kqueue, i.e., the queue itself is process-private.  From my
reading of epoll docs, after fork the child will share the epoll state
with the parent in some sense.

I wonder if it is really useful for the child process to inherit non-fd
knotes?  Maybe such knotes should be ignored.

> Is there some reasons for the proposal to be either architecturally
> unsound, or containing some hard to overcome problems?