Re Pools

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> 
> On Mon, Sep 03, 2001 at 09:24:51PM +0200, B. Fallenstein wrote:
> >
> > No, unfortunately. Needs two blockpools per kind of object that can be
> > created in a view, and a way for some function to know whether to use
> > the first or the second pool. That interaction is actually quite hairy,
> > given that we do not have all the time in the world to determine it--
> > this MUST be fast. (Pass an additional parameter around everywhere
> > !?!?!?)
> 
> It doesn't actually need to be that fast since it only needs to be done once
> for each *factory* when setting up e.g. the text vob production line.

Argument taken.

> VobScene.getPool(java.lang.Class) ?

Too backwards, that would lead into some kind of reflection probably.
Why not

    Vob.getPool(VobScene)

where the VobScene has a field that tells which pool to use? Or, even simpler,

    myVobPool = Vob.pool[scene.poolIndex]

Or hmmm... then it would be harder to release the vobs in them when the
vobscene is thrown away. So Vob.getPool(VobScene), which would add the
pool into a Set in the VobScene, might be best...

> > Also, why remember the "previous length" of the blockpool in the
> > caller, instead of always releasing everything in the pool?
> 
> That's not a problem - calling setSize(0) is fine. Having a parameter just makes
> it more flexible at no cost.

The cost is clarity and simplicity, and clarity and simplicity are
vividly important in internal optimizations which violate the usual way
of doing things anyway. Things are going to be kludgy, but they should
be as unkludgy as we can manage.

I especially do not like having to remember the previous size somewhere.
We could have setSize() as a special case, but for usual pool use (esp.
in views) have a releaseAll() that does the same as setSize(0).
getSize()/setSize() and releaseAll() are then to be used alternatively,
and the programmer must know which one to use; that's a common tradeoff
that has been made in similar situations, too. (Borland's Turbo Pascal
comes to mind, which at some point had two distinct mechanisms to
allocate space on the heap-- and you were *supposed* to use only one of
them in one program.)

-b.