[PATCH] RunnerManager

[Jordi Polo]

On Fri, Apr 25, 2008 at 12:24 AM, Jordi Polo <mumismo at gmail.com> wrote:

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

Thinking a little more about it, using QSharedDataPointer will eliminate the
need of the QReadWriteLock which is nice.
As stated, wait for  opinions.



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



-- 
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/86180ec7/attachment.html