apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR benefits beyond portability for www.asterisk.org
Date Tue, 27 Aug 2002 16:10:24 GMT
At 10:45 AM 8/27/2002, Ryan Bloom wrote:
>On Mon, 26 Aug 2002, TC wrote:
>...  The hardest thing to grasp is the memory pooloing.
> > -how about performance??
>Apache has not suffered from performance problems related to APR, although
>any portable run-time does incur some performance penalty.  We have a
>couple of people who work very hard to ensure that our performance is the
>best that it can be.
> > -stability ??
>APR is stable.  Code written on top of APR is stable, assuming the program
>is written correctly.  As for the library itself, we do still make small
>tweaks to the API occaisionally, but we are finishing all of those up
>now.  You are asking about APR at the best possible time, because we are
>about to release 1.0, and we have stated that the API will not change
>during major releases.

Funny that rbb mentioned pooling and then tried to cover stability and
performance without bringing back up that concept :-)

Memory pooling is what makes apr and pool-based applications relatively
very stable over very long runs, with a huge performance win.  By tying
a transaction's memory and resources to it's own pool, you get very clean
garbage collection for pennies on the dollar, compared to any other garbage
collection schema.  They are worth learning about.

I'd just caution you one point about the API entry points.  Unlike some
other libraries built for robustness-in-spite-of-programmer-error, APR has
very little argument checking for validity.  If it will [safely] segfault, we
leave the segfaults out there as testament to the programmer's mistake.
Only when the bad-argument condition would be nearly undetected, or
open a security hole do we add in argument checking.

For out-of-memory conditions, we consider those fatal [which they are
for nearly any application, and probably the OS is near-death as well.]
We will invoke a registered callback first, but then the application will
be clobbered.


View raw message