[PATCH] RunnerManager

[Jordi Polo]

2008/4/24 Aaron J. Seigo <aseigo at kde.org>:

> On Thursday 24 April 2008, Jordi Polo wrote:
> > There must be some usage of that constructor I am not taking into account
> > because as I see it is only used to create localcontext, and work with
> > them.
>
> it probably is only used currently to create local contexts, but the
> implementation should not work under that assumption since the behaviour is
> not limited to it.
>
> > But the global context that is the one used by interface also, never
> > gets destroyed.
>
> it's not the global context that matters. when the local context goes out
> of
> scope, the d ptr is delete and then we have this:
>
>        ~Private()
>        {
>            qDeleteAll(matches);
>            matches.clear();
>            delete completer;
>        }
>
> so the completer, which is still referenced by other local contexts and the
> global one, gets deleted leaving dangling pointers. the next local context
> that gets destroyed will end up doubly deleting completer. *boom*
>

Got it.



>
> > In fact, if d is going to be QExplicitlySharedDataPointer'd is not the
> same
> > that just let everyone use the same globalContext and kill the
> localContext
> > idea ?
>
> the global context may be changing in the main UI. by having a local
> context
> we avoid race conditions where matches get registered that no longer
> actually
> match the query being added as if they did.
>
> (and looking further, we may do just fine with QSharedDataPointer, even)
>

IIUIC (*) QExplicitilySharedDataPointer makes the classes become basically
alias. So there are multiple names of the same data underneath.
QSharedDataPointer will try to share but if someone writes its own data,
that means it is unique and distintive and it will protect that.

So, QSharedDataPointer will work
 QExplicitilySharedDataPointer will deprecate
SearchContext::addMatchesTo(SearchContext &other), isn't it?  At the cost of
possible but I think not very worrisome contention as context user (runner
threads...) will need to lock for the data.

If I am right I would go for  QExplicitilySharedDataPointer but wait your
opinion.

(*) "If I Understand It Correctly"



>
> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080425/693b9594/attachment-0001.html