[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] tcp: set SPLICE_F_NONBLOCK after first buffer has been spliced
    On 2009/11/05 15:11, Eric Dumazet <> wrote:
    > It cannot, therefore an application uses O_NDELAY to avoid blocking.
    > Try following program if you are not convinced

    Indeed, I'm surprised by the result rendered by the Linux kernel.
    That however still contradicts with the poll() documentation.

    So this boils down to the question: kernel bug or documentation bug?

    "A descriptor shall be considered ready for writing when a call to an
    output function with O_NONBLOCK clear would not block, whether or not
    the function would transfer data successfully."

    There is no size limit mentioned here. Your program reveals that the
    kernel violates this definition.

    > Your patch basically makes SPLICE_F_NONBLOCK option always set
    > (choice 1) above)
    > Why in the first place have an option if it is always set ?

    It is not, you misunderstood my patch. If there's no room in the pipe
    buffer, then the first iteration of the "while" loop will block (as
    usual). *After* the first iteration has finished (and at least one
    buffer has been moved already), the flag is set, and further
    iterations will not block.

     \ /
      Last update: 2009-11-05 15:35    [W:0.023 / U:77.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site