[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [PATCH] RunnerManager
From: "Jordi Polo" <mumismo () gmail ! com>
Date: 2008-04-24 15:46:14
Message-ID: a4162420804240846w7cf37c6k529bd655e5655dbf () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Apr 25, 2008 at 12:24 AM, Jordi Polo <mumismo@gmail.com> wrote:
>
>
> 2008/4/24 Aaron J. Seigo <aseigo@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@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
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Fri, Apr 25, 2008 at 12:24 AM, Jordi Polo <<a \
href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>> wrote:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <br><br><div class="gmail_quote">2008/4/24 Aaron J. \
Seigo <<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>>:<div \
class="Ih2E3d"><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Thursday 24 April 2008, Jordi Polo wrote:<br>
> There must be some usage of that constructor I am not taking into account<br>
> because as I see it is only used to create localcontext, and work with<br>
> them.<br>
<br>
</div>it probably is only used currently to create local contexts, but the<br>
implementation should not work under that assumption since the behaviour is<br>
not limited to it.<br>
<div><br>
> But the global context that is the one used by interface also, never<br>
> gets destroyed.<br>
<br>
</div>it's not the global context that matters. when the local context goes out \
of<br> scope, the d ptr is delete and then we have this:<br>
<br>
~Private()<br>
{<br>
qDeleteAll(matches);<br>
matches.clear();<br>
delete completer;<br>
}<br>
<br>
so the completer, which is still referenced by other local contexts and the<br>
global one, gets deleted leaving dangling pointers. the next local context<br>
that gets destroyed will end up doubly deleting completer. *boom*<br>
<div></div></blockquote></div><div><br>Got it.<br><br> </div><div \
class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
> In fact, if d is going to be QExplicitlySharedDataPointer'd is not the \
same<br> > that just let everyone use the same globalContext and kill the \
localContext<br> > idea ?<br>
<br>
</div>the global context may be changing in the main UI. by having a local \
context<br> we avoid race conditions where matches get registered that no longer \
actually<br> match the query being added as if they did.<br>
<br>
(and looking further, we may do just fine with QSharedDataPointer, even)<br>
<div><div></div><div></div></div></blockquote></div><div><br>IIUIC (*) \
QExplicitilySharedDataPointer makes the classes become basically alias. So there are \
multiple names of the same data underneath. <br>QSharedDataPointer will try to share \
but if someone writes its own data, that means it is unique and distintive and it \
will protect that. <br>
<br>So, QSharedDataPointer will work<br> 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.<br>
<br>If I am right I would go for QExplicitilySharedDataPointer but wait your \
opinion.<br><br>(*) "If I Understand It \
Correctly"<br></div></div></blockquote><div><br>Thinking a little more about it, \
using QSharedDataPointer will eliminate the need of the QReadWriteLock which is \
nice.<br> As stated, wait for opinions. <br><br> </div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><div \
class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">
<div><div><br>
--<div class="Ih2E3d"><br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
</div></div></div><br><div \
class="Ih2E3d">_______________________________________________<br> Panel-devel \
mailing list<br> <a href="mailto:Panel-devel@kde.org" \
target="_blank">Panel-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/panel-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/panel-devel</a><br> \
<br></div></blockquote></div><br><br clear="all"><div><div></div><div \
class="Wj3C7c"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a \
href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo \
Carres<br>NLP laboratory - NAIST<br><a \
href="http://www.bahasara.org">http://www.bahasara.org</a><br>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic