Re: Comprehending subpools

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

<sbelmont700@gmail.com> wrote in message 
news:351c6acd-8a8c-41a3-bb52-dd3f82322829@googlegroups.com...
...
>I'd rather pull all the nonsense of wrapping access values in controlled 
>types
>out of the client in the first place and put it into the pool itself (a 
>callback
>passed to allocate or something?), instead of just solving the problems
>piecemeal.  Having to use controlled types for memory management is the
>problem IMHO.  Let code work with access values directly and leave it to
> the pool they came from to decide how and when to clean it up.

That was my original idea for what eventually became generalized references. 
The problem being that the you have to lie about the specification of pools 
for that to work (the "System.Address" parameters become handles that you 
pass into a a dereferencor). And magic was required for the call-back needed 
to tell the pool when the dereference wasn't needed anymore. Most readers 
couldn't wrap their heads around either part of that.

Using a totally different specification for a new kind of pool wasn't 
appealing, as it would mean having to support multiple ways of doing the 
same thing.

                                                 Randy.

P.S. The original driving force for subpools came from Tucker Taft and Bob 
Duff, who had used a system like this when implementing the tool now known 
as CodePeer. The original proposal was ten times more complicated, 
containing strong and weak references, and automated deallocation 
mechanisms. All of these can easily be constructed with the building blocks 
available, and trying to support all of that would have taken a lot more 
effort.

I've never seen much value for arena memory management myself, but I prefer 
to hide access types as much as possible with almost no visible surface. In 
that case, all of the memory management belongs to the objects, and that 
tends to require separate management for each object.