On Jul 11, 2013, at 2:56 AM, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote: >> On 11 July 2013 02:36, Konstantin Belousov <kostik...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
