From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 16:29:54 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CDDFC666; Wed, 7 Aug 2013 16:29:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F18426FE; Wed, 7 Aug 2013 16:29:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A801B922; Wed, 7 Aug 2013 12:29:50 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: EVFILT_PROC always returns an EV_EOF event Date: Wed, 7 Aug 2013 12:13:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201307251537.04491.jhb@freebsd.org> <20130726185232.GR26412@funkthat.com> <201307261618.19408.jhb@freebsd.org> In-Reply-To: <201307261618.19408.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308071213.28577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 07 Aug 2013 12:29:50 -0400 (EDT) Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:29:54 -0000 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