Re: Custom Storage Pool questions

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:si77kd$rka$1@gioia.aioe.org...
...
> 1. It is a massive overhead in both memory and performance terms with no 
> purpose whatsoever. I fail to see where that sort of thing might be even 
> marginally useful.

The classic example of Finalization is file management on a simple kernel (I 
use CP/M as the example in my head). CP/M did not try to recover any 
resources on program exit, it was the programs responsibility to recover 
them all (or reboot after every run). If you had holes in finalization, you 
would easily leak files and since you could only open a limited number of 
them at a time, you could easily make a system non-responsive.

You get similar things on some embedded kernels.

If you only write programs that live in ROM and never, ever terminate, then 
you probably have different requirements. Most likely, you shouldn't be 
using Finalization at all (or at least not putting such object in allocated 
things).

...
> 2. What is worse that a collection is not bound to the pool. It is to an 
> access type, which may have a narrower scope. So the user could declare an 
> unfortunate access type, which would corrupt objects in the pool and the 
> pool designer has no means to prevent that.

Pools are extremely low-level things that cannot be safe in any sense of the 
word. A badly designed pool will corrupt everything. Using a pool with the 
"wrong" access type generally has to be programmed for (as I answered 
earlier, if I assume anything about allocations, I check for violations and 
do something else.) And a pool can be used with many access types; many 
useful ones are.

Some of what you want is provided by the subpool mechanism, but it is even 
more complex at runtime, so it probably doesn't help you.

                     Randy.