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