httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
Date Thu, 10 Jun 2004 15:46:16 GMT
Brad Nicholes wrote:

>    At least on NetWare, switching to pools would make the code much
> more complex.  Rather than simply calling calloc and free in the same
> way that we are calling apr_rmm_calloc() and apr_rmm_free(), we would
> have to implement essentially the same model using pools and reslists. 
> It seems to me like using a sledge hammer to drive a finishing nail in
> this instance.  Also in the end, it all boils down to malloc and free
> anyway.  As far as debugging goes, I can understand why it might be
> easier using the pool debug code, but we have never been successful in
> making the pool debug code work on NetWare.  Granted we probably haven't
> tried real hard mainly because NetWare already has some good memory
> debugging capabilities built into the OS.  If debugging is a problem, I
> think it might be easier to implement some memory debugging code
> specifically for the LDAP_cache rather than trying to retrofit it with
> pools and reslists.

The theory is that the pools code is already hopefully been 
pre-debugged, you can allocate memory from a pool, and be reasonably 
sure that the problems of freeing the memory is handled for you. (If 
this is not the case, it won't be an LDAP bug, but an Apache wide bug). 
The only real issue really is worrying about the scope of the pool.

Thinking further about this, we could use one pool per cache entry. To 
delete that cache entry just means to destroy the pool. No more need to 
walk the cache entry and delete each buffer one by one, and no room to 
make mistakes. No more chance that somebody adds a field to the cache 
entry, and then forgets the code to free the cache entry.

Creation of the pool would only be done on creation of the cache entry, 
which in turn is done only on the first time this user is authenticated, 
all further requests being cached, so it doesn't seem to be expensive 
either, unless someone with a better understanding of the internals of 
pools would be able to say whether this idea is good or bad.

Regards,
Graham
--

Mime
View raw message