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