From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 23:11:04 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 6826937B401 for ; Mon, 16 Jun 2003 23:11:04 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8DC343F93 for ; Mon, 16 Jun 2003 23:11:03 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 571A85B6CB; Mon, 16 Jun 2003 23:11:02 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Eric Jacobs , freebsd-hackers@freebsd.org Date: Mon, 16 Jun 2003 23:11:01 -0700 User-Agent: KMail/1.5.2 References: <1079.10.0.81.10.1055692530.squirrel@www.mundomateo.com> <20030616171110.GC56734@webserver.get-linux.org> <20030616143936.71007de2.eaja@erols.com> In-Reply-To: <20030616143936.71007de2.eaja@erols.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306162311.01163.wes@softweyr.com> Subject: Re: kqueue alternative? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2003 06:11:04 -0000 On Monday 16 June 2003 11:39 am, Eric Jacobs wrote: > On Mon, 16 Jun 2003 10:11:10 -0700 > > Joshua Oreman wrote: > > On Mon, Jun 16, 2003 at 11:44:15AM +0100 or thereabouts, Tony Finch seemed to write: > > > Select doesn't work with files. > > > > Really? `man 2 select' says nothing about that. It just talks about > > 'file descriptors'. Now if it said 'socket descriptors' or 'non-file > > file descriptors' I would understand, but I don't think that that > > statement is implied by the man page. Is there something I'm missing? > > A file descriptor that references an ordinary vnode (file or directory) > will always be "ready for I/O", because unlike a socket or pipe, it > never needs to block in order to tell you if it's at EOF. > > So, while it works, and is logical, it isn't terribly useful. It's useful from the standpoint that the same select code that works with a device or socket handle, both of which can block, will work with a file handle that can't block or a pipe handle that can block. Looked at in this light, it would be really stupid if select didn't behave as it does when fed a file handle. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com