EVFILT_PROC always returns an EV_EOF event

John Baldwin jhb at freebsd.org
Fri Jul 26 20:20:35 UTC 2013


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.

-- 
John Baldwin


More information about the freebsd-arch mailing list