EVFILT_PROC always returns an EV_EOF event

[John Baldwin]

On Friday, July 26, 2013 4:18:19 pm John Baldwin wrote:
> On Friday, July 26, 2013 2:52:32 pm John-Mark Gurney wrote:
> > John Baldwin wrote this message on Thu, Jul 25, 2013 at 15:37 -0400:
> > > A co-worker ran into this undocumented behavior today.  If you register an 
> > > EVFILT_PROC event but do not set NOTE_EXIT, you can still get an event with
> > > fflags set to 0 but EV_EOF set.  This is not documented in the manpage, and
> > > it seems inconsistent to me.  If the caller hasn't set NOTE_EXIT, then
> > > presumably they do not wish to know about NOTE_EXIT events.
> > 
> > This is probably to let the consumer know that the process no longer
> > exists and that there will be no more events delivered for this process..
> > This allows the process to clean up in this case..  If you look at the
> > code in filt_proc in kern_event.c, you'll also see that is forces
> > _ONESHOT to be set, meaning that the knote will be deleted...
> > 
> > It is someone documented:
> >      EV_EOF         Filters may set this flag to indicate filter-specific EOF
> >                     condition.
> > 
> > But I do agree that the documentation could be better...
> > 
> > I don't have a strong opinion on which behavior is best.  I do think
> > that delivering the EOF is best, since on an fd, you get _EOF when the
> > socket closes, even though you didn't ask for it.. it's implicit..
> 
> Well, processes aren't fd's.  Also, why have both NOTE_EXIT and EV_EOF for
> the same thing?  Also, the doc says "may" for EV_EOF, meaning it's not
> guaranteed (and can not be there if there isn't a filter-specific EOF
> condition).
> 
> It seems to me that the code used EV_ONESHOT as a workaround to cleanup the
> knote since it couldn't do it safely in filt_proc(), but I'm curious what
> other folks think?
> 
> I tried my test on OS X and it does not return the spurious EV_EOF event if
> you don't register for NOTE_EXIT.

Given this last, I'm inclined to commit my change so we are consistent with the
other kqueue implementation in the wild.

-- 
John Baldwin