fewer locks in RunnerContext

[Aaron J. Seigo]

On Wednesday 07 May 2008, Jordi Polo wrote:
> So basically making a copy of a RunnerContext and making a new
> RunnerContext is equivalent?

no; making a copy of RunnerContext::Private makes a new 
RunnerContext::Private. copying RunnerContext itself just copies the existing 
Private*.

> In reset(), if the ResetContext reference count is not greater than 1,
> detach will do nothing, we need to really clean term and friends there.

yeah, i actually already caught that in my local copy.

> Right now the "term" in addMatch and addMatches is what protects from
> runners running on old RunnerContext adding matches to the new
> RunnerContext.

except that this is impossible now. when the term changes in the object ..... 
we now have a new RunnerContext::Private.

right before we change the term, we detach(), then the term is changed, and 
then another round of matching happens. the other threads can do as they 
like, they'll be using a version of RunnerContext::Private that is no longer 
actually in use in the main thread.

for existing threads, the Private object they are working with never changes, 
life goes on as always. but in the main thread, RunnerContext has moved on to 
a new term and a new Private object.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080507/fff37453/attachment.pgp