Andrew Barnert wrote:
> So, you need to change the API. The smallest change, I guess, would
> be to allow the application to pass in its own custom send and recv
> functions for curl to use, but changing it the way I originally
> suggested isn't that much bigger, and it doesn't require you to
> fake poll on top of asio.

I agree, if you have to change the send/recv functions you might as
well go a bit further to make it more flexible.

> By the way, I'm not sure if I mentioned this before, but faking
> asio on top of a poll-type API is trivial and actually pretty
> efficient, while the other way around (basically what you suggested)
> is more complicated and measurably slow. If you're really going to
> force one or the other, forcing asio makes more sense.

I don't agree entirely. It's true that faking epoll-style on top of
async I/O is slow because of extra copying, and more complicated.

But faking async I/O on top of epoll-style wastes a lot of memory, in
reserved buffers, and they are in cold cache. Neither method is
optimal for all scalability issues. For memory use, roughly speaking
epoll-style is better for reading and async I/O is better for writing,
but it depends on details.

-- Jamie
Received on 2008-08-19