From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-28 11:29:03
John Max Skaller wrote:
> Larry Evans wrote:
> > An external entity is, for example, another process? What else?
> Typically, it is a GUI. For example:
> on_click(window_id, data_ptr, callback);
> Here 'data_ptr' is typically an pointer to an object,
> and 'callback' is thunk that calls the 'on_click'
> method of the object. The client might not keep
> a copy of the data_ptr, being able to retrive it
> at any time by, say:
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? And if so, then why wouldn't Boehm's
collector retain it?
I must be missing something. Could you help me out? I've
never programmed a gui.
> > > It remains a disadvantage, whether or not it is unique.
> > > It is also a disadvantage of Greg Colvins cyclic_ptr, on the other
> > > hand my Felix GC system is instance based, and so if one
> > "Instance based" is opposite of "global"? By Felix, you're not referring
> > to the code in flx_gc_1_1.zip, are you?
> Yes: by "Felix GC" I'm refering to flx_gc_1_1.zip.
> [Felix is a language and also the translator for it, the GC
> is part of the run time system]
> >I ask because I see nothing relevant to threads there.
> Exactly. Felix GC isn't thread safe. But you can
> create a collector instance for each thread you create,
> and use it for thread local storage. In that case,
> the collector doesn't _need_ to be thread safe,
> all you need is one for each thread.
Colvin's isn't thread safe because it uses class or static variables
like cyclic_ptr.cpp:boost::un_named::handles? flx_collector can be made safe
because it has no class or static's? 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?
Even so, wouldn't the programmer would have to guard against having a pointer
from one thread referencing an object from another?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk