Messages in this thread | | | Date | Mon, 21 Jun 1999 00:02:59 -0400 (EDT) | From | Zach Brown <> | Subject | Re: async sendfile (was: kHTTPd: Good or Bad) |
| |
On Sun, 20 Jun 1999, Bjorn Wesen wrote:
> could you (or someone else) elaborate on the issues with sendfile and > asynch sendfile ? I'm curious..
sure..
> The current sendfile() is blocking right, so you basically need a fork() > for serving a file ? And that an asynch sendfile would start the > operation, return immediately, kernel fiddles with pages and sockets, and > delivers a signal when done ?
It doesn't have to be blocking, it can return EAGAIN. That will make sense when zero copy gets here for big machines, but its current point is to reduce the syscall overhead of i/o by blocking and doing it all in one go.
> And this is faster than using non-blocking separate write()'s from mmap'ed > files in a select() loop (single thread model).
yeah. less churn and no mmap() overhead.
> If so, what does the sigio patches you mention do ?
the sigio patches are a different beast entirely. they add siginfo structs for poll events on sockets. So you get sigio signals when things happen to sockets and you get siginfo structs with them that says what fd it happened to and just what it was that happened. that last part is why all this is so cool. You get single quick notifications when something happens, rather than spinning in poll()/select(). Its an efficient way of doing i/o across lots of file discriptors in one context of execution.
the async sendfile stuff is yet another beast. imagine us doing this non blocking sigio event engine, spinning on lots of sockets. we want to deal with lots of data, more than will sit in the socket queues so we have to spin on read/write and falling back to the i/o engine when it would block, the io engine tells us when we can continue. with async sendfile, however, we could simply issue the sendfile() and get an event when its done (say, POLL_OUT or something on the descriptor).
-- zach
- - - - - - 007 373 5963
- 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/
| |