Re: hacking - aio_sendfile()

On Jul 11, 2013, at 2:56 AM, Konstantin Belousov <kostikbel_at_gmail.com> wrote:

> On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote:
>> On 11 July 2013 02:36, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
>> 
>>> No, it is not disk I/O which is problematic there. It is socket I/O
>>> e.g. wait for the socket buffers lomark in the kern_sendfile() which
>>> causes unbounded sleep. Look for the sbwait() call, both in the
>>> kern_sendfile() itself, and in the pru_send methods of the protocols,
>>> e.g. in sosend_generic(). The wait scope controlled by the other side of
>>> connection and allow it to completely block the aio subsystem.
>>> 
>>> Disk I/O is supposed to finish in the finite time.
>> 
>> Even if the destination socket is marked as NONBLOCK?
> 
> You mean, would a sleep for the socket buffer space cause aio thread
> block is the socket is put in nonblocking mode ?  Or something else ?
> 
> No, it would not block the thread. But I cannot consider the
> aio_sendfile(2) implementation useful if it requires non-blocking
> socket. Also, what about other thread changing the socket to blocking
> mode while sendfile is in flight ?

Just as with other aspects of sendfile, it's up to the caller to protect this kind
of state.  Objecting to aio_sendfile() simply for the reason you state is absurd
and against the design goals of sendfile.

Scott