gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog server/character.cpp


From: zou lunkai
Subject: Re: [Gnash-commit] gnash ChangeLog server/character.cpp
Date: Tue, 18 Dec 2007 09:20:19 +0800

On Dec 18, 2007 1:52 AM, strk <address@hidden> wrote:
> On Mon, Dec 17, 2007 at 07:41:43AM +0000, Zou Lunkai wrote:
> > CVSROOT:      /sources/gnash
> > Module name:  gnash
> > Changes by:   Zou Lunkai <zoulunkai>  07/12/17 07:41:43
> >
> > Modified files:
> >       .              : ChangeLog
> >       server         : character.cpp
> >
> > Log message:
> >       * server/character.cpp: remove the assertion in charcter::destroy(), 
> > it's not
> >         correct as tests confirmed.
>
> Zou, the assertion is there to sustain assumptions we make in the code.
> For example, void movie_root::cleanupUnloadedListeners(CharacterList& ll)
> uses isUnloaded() to decide wheter or not to drop references to characters,
> as movie_root::cleanupDisplayList() does with _liveChars.
>

I understand, then the assumption is not correct.   And if we insist
this assumption,  always setUnloaded in ::Destroy() would be a
solution, but it's not an assumption any more.

> If we allow a character to return true from isDestroyed() w/out returning
> true from isUnloaded() we'll keep alive a lot of stuff.
>
> Planarity big might be one such case (https://savannah.gnu.org/bugs/?21782)
> or others...
>

Keep characters alive in the GlobalList and some listenereList, right?
  That's because ::CleanUpDisplayList()  and
::cleanupUnloadedListeners  only take care of the unloaded characters
and *assume* all destroyed characters are unloaded.  This assumption
is debatable now, please review testcase new_child_in_unload.c.

> In any case, the state of a character can not go to destroyed w/out being
> first unloaded. call both unload() and then destroy() if needs be, or
> make destroy() set _unloaded.
>

"make destroy() set _unloaded" might work practically,  let's just
consider the interface for a while...

--zou




reply via email to

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