On Thu, 25 Sep 2014 05:26:38 -0700 Paul Querna <p...@querna.org> wrote:
> On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski <j...@jagunet.com> > 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. I can give you a data point on memory management from the experience with event driven/async programming in the Samba project. There we use talloc, a hierarchical memory allocator, and we find it a great match for event driven/asynchronous models as it allows automatic cleanup of memory and other resources (like file handles) via destructors, yet each memory context can be really fine grained and tied well to the memory structures being used. I find pools extremely handy, but adding a hierarchical layer on them could make them better suited for event driven/asynchronous request mechanisms. my 2c, HTH. Simo. -- Simo Sorce * Red Hat, Inc * New York
