Re: [boost] Smart pointer status, directions, thoughts

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-28 21:33:14

Larry Evans wrote:
> 
> John Max Skaller wrote:

> >         on_click(window_id, data_ptr, callback);

> I still don't understand.  If data_ptr points somewhere in the
> heap, then it's got to be reachable via some path from the
> root pointers.  Right? 

        No, it doesn't _have_ to be reachable.
For example:

        on_click(window_id, new ClickHandler(), callback);

Here, the ClickHandler object isn't reachable from user space.
The user will have to so this:

        void *p = ClickHandler();
        register_root(p);
        on_click(window_id, p, callback);

to make it a root, to stop the collector zapping it.
And, more difficult, make sure to unregister it as
a root when the window is destroyed (to make
sure the collector then _does_ collect it).

> Colvin's isn't thread safe because it uses class  or static variables
> like cyclic_ptr.cpp:boost::un_named::handles?  

        Yes. More precisely, when linking or unlinking objects
from the linked list, there is a critical section that needs to
be protected by a mutex, to stop another thread getting in,
and scambling the list.

        Felix GC is exactly the same. It isn't thread safe.

> flx_collector can be made safe
> because it has no class or static's?  

        It can't be 'made' thread safe, however it can be _used_
in a way that is thread safe.

If that's right, then couldn't Colvin's
> be secured in the same way, by replacing every static with an instance variable
> in a class, cyclic_collector?

        Absolutely, yes. The constructor that takes a raw pointer
argument just needs an instance argument representing the list
that instance manages. The change is trivial. 
 
> Even so,  wouldn't the programmer would have to guard against having a pointer
> from one thread referencing an object from another?

        Yes. But the danger here isn't just for threads:
it is a problem if you have two instances of the collector,
even when there is only one thread. This means the
objects/pointers of a collection set can be disjoint.
In Felix, though, there are other architectures.

        You can build a tree of collectors with weak
uplinks provided you zap the collectors for the child
nodes before collecting the parent nodes. As long as
you are using pure garbage collection, the uplinks
will find parent objects, even if they aren't reachable.

        I'm not sure if that will work with Colvin's cyclic_ptr
(since it is essential with this design NOT to use ref counting)

        As an example: a List<T> with its own collector.
Consider a List<List<T> >. Deleting a node of the outer
list kills the collector of the inner list, destroying
all the elements. This is 'functionally' equivalent
to using destructors except that it doesn't involve
recursion (which can be eliminated from a list node
destructor only if the compiler recognizes tail recursion).
 
-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net