lkml.org 
[lkml]   [2004]   [Oct]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromJeff Moyer <>
DateMon, 18 Oct 2004 12:51:28 -0400
SubjectRe: [patch rfc] towards supporting O_NONBLOCK on regular files
==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; Alexandre Oliva <aoliva@redhat.com> adds:

aoliva> On Oct 17, 2004, Ingo Molnar <mingo@redhat.com> wrote:
>> I.e. the readahead-kicking is necessary after all, because squid
>> apparently assumes that re-trying a read will eventually succeed.

aoliva> I'm not sure it assumes that.  It definitely expects read to
aoliva> succeed if poll says there is data available from the file, though,
aoliva> and having poll return that there is data, and then having read
aoliva> fail because there isn't anything there, so that you go back to
aoliva> poll, is a recipe for wasting CPU.  I do think read should kick in
aoliva> readahead, yes, but so should poll, if the process says it wants to
aoliva> read from the file, and poll should not return (or not say data is
aoliva> available) unless an immediate, atomic call to read would actually
aoliva> return some data.  Of course, if the data happens to be elicited
aoliva> from memory between the poll and read calls, it's legitimate for
aoliva> read to fail with -EAGAIN, but this shouldn't happen very often.

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!

Since it wasn't supported before, I see no need to extend select/poll to
change behaviour for regular files.  After all, the POSIX spec explicitly
says that select and friends will always return data ready for regular
files.  To make O_NONBLOCK on regular files a workable implementation, Uli
suggestsed extending epoll.  I will look into this.

I am in favor of kicking off I/O for reads that would block.

-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [from the cache]
©2003-2008