At 06:09 PM 7/6/2007, John Gilmore wrote:
> This is more a problem as long as both GC and RC implementations are
> intrusive. If we store intrusive_ptr in a class member, and the
> instance pointed-to is destroied by the GC, a segfault would happen
> when the intrusive_ptr destructor is is invoked.
I don't understand this part. By definition, we'd never free
something that has an active pointer to it -- either in RC or GC
models. So how could we ever get a segfault from referencing
such a pointer?
From the intrusive_ptr documentation:
The intrusive_ptr class template stores a pointer to an object
with an embedded reference count.
When you invoke an intrusive_ptr destruction, its precondition is that the
object exists, because it decrements a reference count that exists within
the pointed-to object. Now suppose there had been some object that was
already destroyed by another mechanism (GC in the example above) and there
yet remains an intrusive_ptr to it. When that intrusive_ptr goes out of
scope, its destructor is called, which then tries to decrement a no-longer
existent object. At best, you get a segfault if the address has left its
process's memory space. At worst, you get a decrement on some random piece
of memory.
The point he's making is that you can't mix GC and intrusive_ptr semantics
between pointers referencing any given class. Once you put some object
under GC control, all references to it must also be under GC, because
otherwise you end up with the above misbehavior.
Eric
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
