3 ms·

IIRC, kqueue can be told to read the whole http-request before letting client know there's data to read.

• rdtsc 15y ago
  How does it work? Do users provide a buffer and the kernel fills the buffer with data and notifies the user when ready? That is more akin to AIO Linux system, then? Otherwise, epoll/poll/select just notifies users when data is available but the actual copy is done by the user. Surprisingly this can make a huge difference when streaming large amounts of data. http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-an... We have argued here before and I have gotten downvoted into oblivion for being pedantic and distinguishing between asynchronous IO and non-blocking IO but it looks like that extra user-space memcpy can make a huge difference.
  • Flow 15y ago
    I can't find anything about this now, just spent a good 20 minutes searching for it. I guess keywords kqueue, buffer request http are too generic in some sense. :-/ Anyway, the idea was to avoid context switches by waiting/parsing in kernel-side till there was enough data for the client to do something else that just another gimme_more_data()-call back to the kernel. It could even be applied to other methods than kqueue, so perhaps I remember a bit wrong that this was just for kqueues.
• gorset 15y ago
  That's actually accept_filter(9). The man page for freebsd has a interesting info: The accept filter concept was pioneered by David Filo at Yahoo! and refined to be a loadable module system by Alfred Perlstein. The closest you can get by using kqueue is to set a low water mark, so that a read event is only returned when there's enough data ready.
  • Flow 15y ago
    Ah, that's it! Thanks for finding it.