But sendfile() calls to nonblocking sockets are likely to be
fairly short. One could switch the socket to blocking mode before
transferring a large file, but then you'd need one thread per
client, which is what we're trying to avoid by using sigwaitinfo()
to multiplex many clients onto one process! So that lazy-TLB
feature is neat, but might not help too much in this case.
> > In a web server, one can use sigwaitinfo() (or poll()) to efficiently
> > multiplex many clients onto one thread. If the client asks for a flat
> > file, one can use sendfile() to avoid the overhead of copying the data
> > to userspace and back. To avoid the problem of sendfile() blocking
> > all the clients when it has to read from disk, one can have worker
> > threads do all the sendfiles.
>
> Yes, and in principle it would be possible to make the sendfile
> completely asynchronous, essentially by doing the disk IO asynchronously
> from a dedicated kernel thread.
What kind of limits would there be on the number of outstanding
aio_sendfile()'s?
Would the dedicated kernel thread handle just one sendfile(),
or multiple ones?
- Dan
-- (The above is my opinion alone, and not that of my employer)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/