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.

Cheers
-- 
^(TM)

Mime
View raw message