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