apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: APR shared memory requirements.
Date Wed, 09 May 2001 21:25:41 GMT
>> that may be the case, however when you don't enable POOL_DEBUG,
>> it doesn't _do_ anything!  the guarantees, esp. if the behaviour
>> of the program is affected _by_ enabling POOL_DEBUG, are almost
>> worthless.

Actually, the implementation of the memory system code depends
heavily on asserts and some debug code is only executed when
APR_MEMORY_SYSTEM_DEBUG is defined.
Maybe APR_MEMORY_SYSTEM_DEBUG should just be set when normal
debugging is enabled?

> They only do one thing -- they tell the maintainer that someone just
> committed something rather clueless.  Dean (and myself when I had time)
> used to compile httpd 1.3 with ALLOC_DEBUG and POOL_DEBUG on all the time
> in order to catch places where modules were combining memory from multiple
> pools.  It is not intended to be a run-time check for deployed systems
> because that would add pointless overhead (there is no recovery
> path anyway).
> It may not work right now in 2.0, since I recall someone monkeying with
> the code because it wasn't thread-safe.
>
> You will need the same kind of thing for stackable memory systems
> -- there
> needs to be a way for a developer to ensure that data allocated within a
> data structure is as long-lived as the data structure itself.

Could you expand on this? Ie, give a small example (I probably have in
my head what you mean, but I want to make sure)?

> .....Roy

Sander


Mime
View raw message