Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Jun 2003 23:11:01 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Eric Jacobs <eaja@erols.com>, freebsd-hackers@freebsd.org
Subject:   Re: kqueue alternative?
Message-ID:  <200306162311.01163.wes@softweyr.com>
In-Reply-To: <20030616143936.71007de2.eaja@erols.com>
References:  <1079.10.0.81.10.1055692530.squirrel@www.mundomateo.com> <20030616171110.GC56734@webserver.get-linux.org> <20030616143936.71007de2.eaja@erols.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 16 June 2003 11:39 am, Eric Jacobs wrote:
> On Mon, 16 Jun 2003 10:11:10 -0700
>
> Joshua Oreman <oremanj@www.get-linux.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306162311.01163.wes>