apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: apr-2 pool status [Was: Poor performance with new apr_pool]
Date Wed, 01 Apr 2009 09:22:17 GMT
Sander Striker wrote:
>> ... and yes, can we get rid of the POOL_DEBUG.
>> It totally breaks the apr concept of a clean API,
>> and doubles the pool code without (at least to me)
>> any good reason.
> Darn, you almost had me there (April Fools!).  Just in case you were
> being serious, the pool debug code has certainly helped track down
> memory allocation related issues in several applications.  The [old]
> pools logic masks a lot, and is therefor not so useful in combination
> with tools like valgrind, duma, etc.

If after all those years you still make bugs, what's the point man?

But seriously, the debug pool api is something
that simply doesn't fit in the apr. If it does, I certainly
know few places in the apr where debug api would help.
I volunteer to write the extra debug api for critical apr objects
like files, mutexes and sockets. Beside, I have nothing
else to do with my life. I mean I always wondered how many
times the EINTR is happening inside socket_read. That would be
kind a cool to know for any nerd out there.


View raw message