Re: [patch rfc] towards supporting O_NONBLOCK on regular files

[Alexandre Oliva <aoliva@redhat.com>]

On Oct 18, 2004, Jeff Moyer <jmoyer@redhat.com> wrote:

> Select, pselect, and poll will always return data ready on a regular file.
> As such, I would argue that squid's behaviour is broken.  Additionally, I
> don't think it's a good idea to modify any polling mechanism to kick off
> I/O, if simply because I'm not sure how much data to request!

You could request a single block (whatever that means), and then the
subsequent non-blocking read would stand a chance of eventually making
progress.  .  Or you could request nothing, and have the actual read
start a readahead, such that next time it hopefully will have
something to get to immediately.  If the read comes in too quickly,
before the poll-initiated readahead completes, you'll probably get
them merged anyway, so it's not like it could hurt, methinks.

And then, you might arrange for select/poll to not return immediately
for these file descriptors, but rather return as soon as one of them
has some data available to read, the time-out expired, or a very short
time-out set for the case of non-blocking file descriptors select()ed
for read expired.  The latter time-out should be short enough to be
hardly distinguishable from an immediate return, and the return value
should be exactly what a POSIX-compliant application expects.

This doesn't quite fix the problem with the existing standard
interfaces, that don't quite enable anyone to do non-blocking reads
without explicit readahead advice and busy-waiting for data.  The
short time-out above should at least reduce the syscall explosion that
we get with the current behavior, but if read kicks in a readahead to
guarantee we'd eventually get out of the select/read loop without
external help to bring the data into memory, I guess we could live
without the select/poll changes.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}