<br><br><div class="gmail_quote">On Fri, Apr 25, 2008 at 12:24 AM, Jordi Polo &lt;<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>&gt; 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 &lt;<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>&gt;:<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>
&gt; There must be some usage of that constructor I am not taking into account<br>
&gt; because as I see it is only used to create localcontext, and work with<br>
&gt; 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>
&gt; But the global context that is the one used by interface also, never<br>
&gt; gets destroyed.<br>
<br>
</div>it&#39;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>
 &nbsp; &nbsp; &nbsp; &nbsp;~Private()<br>
 &nbsp; &nbsp; &nbsp; &nbsp;{<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;qDeleteAll(matches);<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;matches.clear();<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;delete completer;<br>
 &nbsp; &nbsp; &nbsp; &nbsp;}<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>&nbsp;</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>

&gt; In fact, if d is going to be QExplicitlySharedDataPointer&#39;d is not the same<br>
&gt; that just let everyone use the same globalContext and kill the localContext<br>
&gt; 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>&nbsp;QExplicitilySharedDataPointer will deprecate SearchContext::addMatchesTo(SearchContext &amp;other), isn&#39;t it?&nbsp; 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&nbsp; QExplicitilySharedDataPointer but wait your opinion.<br><br>(*) &quot;If I Understand It Correctly&quot;<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&nbsp; opinions. <br><br>&nbsp;</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>&nbsp;</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 &nbsp;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>