[lkml]   [2004]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch rfc] towards supporting O_NONBLOCK on regular files
    ==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; Alexandre Oliva <> adds:

    aoliva> On Oct 17, 2004, Ingo Molnar <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:07    [W:0.027 / U:4.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site