httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simo Sorce <s...@redhat.com>
Subject Re: What's need for http/2.0?
Date Thu, 25 Sep 2014 12:44:21 GMT
On Thu, 25 Sep 2014 05:26:38 -0700
Paul Querna <paul@querna.org> wrote:

> On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski <jim@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

Mime
View raw message