Mike Silbersack wrote this message on Tue, Nov 04, 2003 at 11:02 -0600: > Suppose that sendfile is called to send to a non-blocking socket, and that > it detects that the page(s) required are not in memory, and that disk I/O > will be necessary. Instead of blocking, sendfile would call a sendfile > helper kernel thread (either by calling kthread_create, or by having a > preexisting pool.) After dispatching this thread, sendfile would return > EWOULDBLOCK to the caller. Note that only a limited number of threads > would exist (perhaps 8?), so, if all threads were busy, sendfile would > have to block like it does at present. > > Once the I/O was complete, the thread would call sowakeup (or whatever is > called typically when a thread is now ready for writing) for the socket in > question. The application would call sendfile, like normal, but this time > everything would succeed because the page would be in memory. > > --- > > If such a feature were implemented, it might have the same increased > performance effect that your new return value does, except that it would > require no modification for a non-blocking sendfile based application to > take advantage of it.
This would not work with kqueues as kevents are level triggered, not edge... so, this idea is bad/broken. I don't even think it would work with select since when you call select, it will check the availabilty of writing at the select call time.. You'd have to add a flag to the fd so mark it as delayed for another reason.. I don't think this feature can be cleanly added w/o somehow tieing fd's together. One call that I would like to see is a fd to fd copy. You pass in both fd's with maybe a length, and then a kernel helper thread does the copy or something. This would have other uses in that you can then "plumb" pipes between programs in a more effecient manner... This would also possibly fix/replace sendfile as sendfile isn't more different. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"