Update: Debox sendfile modifications

[Igor Sysoev]

On Wed, 5 Nov 2003, Mike Silbersack wrote:

> On Wed, 5 Nov 2003, Vivek Pai wrote:
> 
> > If you were to have sendfile issue the disk reads, how would you signal
> > completion? I guess one approach is to make the socket buffer appear to
> > have no space while the sendfile-initiated read is in progress, but
> > it seems to me that such an approach would be considered too ugly. It
> > would cause the least modification to applications, because otherwise
> > apps need to disable interest on the socket having space, and re-enable
> > it after getting notified that the sendfile-initiated read (and
> > transfer) completed. Am I missing something?
> >
> > -Vivek
> 
> I'm not quite certain how I would do it yet.  At this point in time I'm
> just brainstorming.  I have some other things I'd like to work on in the
> next few weeks, I'll sit down and think about this more in late November /
> early December if I'm still in the right mindset.

I think it can done in the following way - a socket should have flag
that says that sendfile() had started the reading a page.
select()/poll()/kevent() should check this flag before the checking
a socket buffer space.  When the page had been read this flag is reset.
If there was error while a reading a page then second flag should be set and
the first one should be reset.  sendfile() should check the error flag
before processing.  If it set then sendfile() should do a blocking read()
to learn errno.  I think that this blocking read() would not occur under
normal conditions and would not decrease perfomance.  And if we have file
errors we should think not about perfomance but about correctness of a whole
server.

I think it would be transparent to the existent user applications
that uses select()/etc.


As to worker kthreads I think it's better to queue aio operation
as it was made in src/sys/kern/vfs_aio.c:aio_qphysio().


Igor Sysoev
http://sysoev.ru/en/