[Top][All Lists]

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

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

From: Bastiaan Jacques
Subject: Re: [Gnash-commit] gnash/server dlist.cpp
Date: Thu, 24 Aug 2006 01:34:23 +0200
User-agent: KMail/1.9.4

On Wednesday 23 August 2006 23:44, strk wrote:
> On Wed, Aug 23, 2006 at 05:03:11PM +0200, Bastiaan Jacques wrote:
> > What about:
> >
> > for (iterator it = _characters.begin(); it != _characters.end();
> > ++it) { // ..
> > }
> >
> > ?
> >
> > This would save you a copy and (I believe) would be safer than the
> > original.
> If the container can change (as the comments suggest)
> we need more info about "how" could it change, as I don't think
> that testing for .end() would be enough to be "safe".

Right, so, the question is: can the container change size in between the 
_characters.end() call and when we use it?

The answer is probably yes. It's significantly less likely if you check 
in each iteration, but it can still happen.

One solution is to have a copy of the container. This, of course, has 
its downsides: if we advance a character that has been deleted in the 
original character list, it may be there for too long (and we may 
render something that should already be gone). And of course we copy 
the character list itself, which uses memory and processor time.

Another solution would be to make this function a 'critical section' in 
a threading context: this will ensure that nobody can delete anything 
until we've finished advancing our whole character list.

The best solution would be, I think, is to maintain an owning reference 
to the character we are attempting to use. So, if someone is trying to 
delete the character we are using, we make them wait until we've 
released our hold on the character.

I'm not sure how much work would be involved in doing that, though.

> BTW, I've verified in the past that testing for .end() or .size() and
> friends in a for condition is actually slower then caching it in
> the initializer.

Yes, that makes sense.


reply via email to

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