[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] sendfile removal

    On Fri, 1 Jun 2007, H. Peter Anvin wrote:
    > Fair enough. Unix has traditionally not acknowledged the possibility of
    > nonblocking I/O on conventional files, for some odd reason.

    It's not odd at all.

    If you return EAGAIN, you had better have a way to _wait_ for that EAGAIN
    to go away, otherwise the EAGAIN is just a total waste of time.

    So the rule about EAGAIN is very simple:
    (a) the file descriptor must be O_NONBLOCK
    (b) the access must otherwise block
    (c) the condition must be something we can wait for with poll/select

    I don't know why people continually ignore that (c) point, even though
    it's obvious and very very important!

    If you cannot wait for it, tell me why the kernel should _ever_ return
    EAGAIN? The only option for the user is to just do the operation again

    And the thing is, neither poll nor select work on regular files. And no,
    that is _not_ just an implementation issue. It's very fundamental: neither
    poll nor select get the file offset to wait for!

    And that file offset is _critical_ for a regular file, in a way it
    obviously is _not_ for a socket, pipe, or other special file. Because
    without knowing the file offset, you cannot know which page you should be
    waiting for!

    And no, the file offset is not "f_pos". sendfile(), along with
    pread/pwrite, uses a totally separate file offset, so if select/poll were
    to base their decision on f_pos, they'd be _wrong_.

    This really is very fundamental.

    Now, you can argue that you can always just return -EAGAIN anyway, but
    then the calling process will basically be busy-looping, calling
    sendfile() (or splice()) over and over again. That's _horrible_. It's much
    better to just not return EAGAIN, and sleep like a good process should!

    So there's a few things to take away from this:

    - regular file access MUST NOT return EAGAIN just because a page isn't
    in the cache. Doing so is simply a bug. No ifs, buts or maybe's about

    Busy-looping is NOT ACCEPTABLE!

    - you *could* make some alternative conventions:

    (a) you could make O_NONBLOCK mean that you'll at least
    guarantee that you *start* the IO, and while you never return
    EAGAIN, you migth validly return a _partial_ result!

    (b) variation on (a): it's ok to return EAGAIN if _you_ were the
    one who started the IO during this particular time aroudn the
    loop. But if you find a page that isn't up-to-date yet, and
    you didn't start the IO, you *must* wait for it, so that you
    end up returning EAGAIN atmost once! Exactly because
    busy-looping is simply not acceptable behaviour!

    I have to admit that I didn't look at what raw splice() itself does these
    days. I would not be surprised if Jens also didn't realize this very
    fundamental issue. It seems too easy to miss, because people think
    that EAGAIN stands on its own, and don't realize that EAGAIN must be
    paired with select/poll to make sense.


    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: 2007-06-01 18:23    [W:0.033 / U:5.444 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site