From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 10:41:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C38B616A4CE for ; Wed, 12 Nov 2003 10:41:29 -0800 (PST) Received: from naughty.monkey.org (naughty.monkey.org [66.93.9.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6368C43F85 for ; Wed, 12 Nov 2003 10:41:02 -0800 (PST) (envelope-from marius@naughty.monkey.org) Received: by naughty.monkey.org (Postfix, from userid 6) id 289A41BA96F; Wed, 12 Nov 2003 13:40:42 -0500 (EST) Date: Wed, 12 Nov 2003 13:40:42 -0500 From: marius aamodt eriksen To: Bill Studenmund Message-ID: <20031112184042.GC2942@monkey.org> Mail-Followup-To: Bill Studenmund , Jaromir Dolecek , hackers@openbsd.org, tech-kern@NetBSD.org, freebsd-hackers@freebsd.org, Niels Provos References: <20031110174109.GA13852@monkey.org> <200311120858.hAC8wFfg001905@s102-n054.tele2.cz> <20031112172750.GB14368@netbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031112172750.GB14368@netbsd.org> User-Agent: Mutt/1.3.99i cc: freebsd-hackers@freebsd.org cc: Niels Provos cc: hackers@openbsd.org cc: Jaromir Dolecek cc: tech-kern@NetBSD.org Subject: Re: kqueue, NOTE_EOF X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: marius@monkey.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 18:41:29 -0000 * Bill Studenmund [031112 12:27]: > > I'm not sure I understand what is the exact issue. > > I'm only responding to the notes also. > > > Why would this be necessary or what does this exactly solve? AFAIK > > poll() doesn't set any flags in this case neither, so I don't > > see how this is inconsistent. > > I think the difference is in the default behavior. When you're at EOF, I > know that poll() will give you a read-availability event, so you'll read > the EOF. Will kqueue? correct - this is the difference, kqueue will not yield any event at EOF. > > BTW, shouldn't the EOF flag be cleared when the file is extended? > > Probably. i'm not sure this is an issue - at the point where EOF is determined, the kqueue event returns success. and in this case, the event is always successful, so the process will not sleep on the kevent() call. in a preemptible kernel, there is a race between the EOF condition is determined and kevent() actually returns. semantically, in this case it makes sense to cancel the event (for which there is no infrastructure), and not necessarily clear its flag. though in this case, that hack will work correctly. marius. -- marius a eriksen | http://monkey.org/~marius/