[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] GC: status report & call for test

From: Eric Hughes
Subject: Re: [Gnash-dev] GC: status report & call for test
Date: Fri, 06 Jul 2007 20:41:32 -0600

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]