On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski <[email protected]> wrote: > APR: > Considering that before we know it, http/2.0 will > be here, and ignoring httpd for the time being, > what features/additions do we see as being needed > to support http/2.0 from an APR library level? How do > we compare w/ libuv, for example? How "event-aware" > should APR be, ala libevent?
On APR: I mean. It's a platform layer over OS syscalls. it works. But... Having has a hand in early libuv development: libuv is fundamentally different -- everything is event based, anything that isn't able to be 'natively evented' into the OS event loop is dispatched to a thread pool. __This is nice because it gives you a constant abstraction to IO operations, not just the OS syscalls.__ APR lacks this POV. This has trade offs. Most commonly, File IO, as you need to do a blocking IO operation in another thread, which means you add a context switch or three to do IO. However with the changes to framing in http2, the days of just sendfile()'ing a file and blocking a thread are basically over, so maybe its not a huge deal in the end. As libuv was designed to be embedded in garbage collected languages, libuv also does not adopt pools. From my experience pools also tend to be harder to keep fine grained in most evented models, but this doesn't mean they couldn't be layered on top with care. My POV: I'd just use libuv, and port any APR-Util code to a library on top of libuv if it is needed. I'd probably keep pools for module level code using requests, but I'm unsure about connection pools honestly.
