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.
Bill
