gnash-dev
[Top][All Lists]
Advanced

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

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


From: John Gilmore
Subject: Re: [Gnash-dev] GC: status report & call for test
Date: Fri, 06 Jul 2007 17:09:56 -0700

> > Second, the code that creates circular reference structures KNOWS that
> > it's creating them, much of the time.  When we disassemble such a
> > structure, in reference counting mode, we should disassemble it
> > despite the circular references.
> 
> It doesn't always know, as the default relation is just a default.
> Users (ActionScript coders) can still change this relationship.
> a function's "constructor" member is a pointer to self, but
> might be changed to point to something else:
> 
>       A = function() {}
>       B = function() {}
>       A.prototype.constructor = B.prototype.constructor;
>       delete A;
> 
> In the case above, A.prototype.constructor would be destroyed by
> last line, while still in use by B, which is alive.

Right.  OK, so the structure has to remember whether the pointer it
currently contains is circular or not.  No big deal.

Make XXX.prototype.constructor a sometimes_circular_ptr, containing an
is_refcounted flag which says whether it is circular or not.  If an
ordinary intrusive_ptr is assigned to a sometimes_circular_ptr,
is_refcounted is set to 1, and the reference count is incremented (and
will be decremented on release).  If a known circular reference is
being made, e.g. in function creation, then you call a specialized
function with this effect: the is_refcounted member is set to 0, and
the reference count won't be incremented (nor decremented on release).

I looked at implementing this stuff in gnash, but it was a tangle of
our code and boost's code, and it brought out my hatred of C++, and
eventually I gave up on the mechanics.  Strk can probably do it in a
few minutes, if he likes the idea.

> 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?

        John




reply via email to

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