lkml.org 
[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sendfile removal
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 :)

-
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: 2007-06-01 09:27    [W:0.163 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site