[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:24:07
Message-ID: a4162420804240824i75d4a73eh920b55171acc3c1c () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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"
>
> --
> 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
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">2008/4/24 Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">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 class="Ih2E3d"><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 class="Ih2E3d"></div></blockquote><div><br>Got \
it.<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="Ih2E3d"><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 class="Wj3C7c"></div></div></blockquote><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><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 class="Wj3C7c"><br>
--<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><br>_______________________________________________<br>
Panel-devel mailing list<br>
<a href="mailto:Panel-devel@kde.org">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></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