Re: [PATCH] sendfile removal

[Eric Dumazet <dada1@cosmosbay.com>]

H. Peter Anvin a écrit :
> Jens Axboe wrote:
>>> I would personally argue that sendfile() blocking on an O_NONBLOCK
>>> desriptor, as opposed to returning EAGAIN, is a bug, and a fairly
>>> serious such.
>> I agree, but it's still a change in behaviour. Even if we consider the
>> app buggy (it is), can we potentially break it?
>>
> 
> It depends on which app it is, of course.  However, I think we have to
> smoke that out the hard way.  I don't think we should retain a bug in
> the kernel just because some unknown app might depend on that bug --
> taking that to the extreme  we could never fix bugs at all...
> 

As I said, this new non blocking feature on the input side (disk), is nice and 
usefull. (For people scared by splice() syscall :) )

Just have to mention it is a change of behavior, and documentation probably 
needs to reflect this change. "Since linux 2.6.23, sendfile() repects 
O_NONBLOCK on in_fd as well"


My man page here says :

ERRORS
        EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and the 
write would block.

        EBADF  The input file was not opened for reading or the output file 
was not opened for writing.

        EFAULT Bad address.

        EINVAL Descriptor is not valid or locked, or an mmap()-like operation 
is not available for in_fd.

        EIO    Unspecified error while reading from in_fd.

        ENOMEM Insufficient memory to read from in_fd.


This implies O_NONBLOCK on the out filedesc, not the input one :)