<br>So basically making a copy of a RunnerContext and making a new RunnerContext is equivalent?<br><br>In reset(), if the ResetContext reference count is not greater than 1, detach will do nothing, we need to really clean term and friends there.<br>
<br>Right now the "term" in addMatch and addMatches is what protects from runners running on old RunnerContext adding matches to the new RunnerContext.<br>As discussed, we can clean the jobs queue but no mechanism is in place to kill currently running runners, if they take a long time (and this is the kind of thing with the potential of happening only in some circunstances of some systems) they will be running and will complete when we already have a new RunnerContext (user typed a new letter), right now, they present "term" as the credential of what they are working on, so old matches can not be added to new contexts. <br>
<br><br><div class="gmail_quote">2008/5/8 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;">
hi all..<br>
<br>
the data members of RunnerContext are now read-only for all intents and<br>
purposes: when the query term is set, the data is first detached creating a<br>
new set of data members to operate on. the RunnerContext API enforces this<br>
pattern.<br>
<br>
this means that we *should* be able to get rid of a number of locks<br>
completely, such as the read lock in query() -> QString is reentrant, the<br>
data is never being written to ... so no lock is needed.<br>
<br>
really, the only thing we need to lock aggressively is access to matches list.<br>
<br>
moreover, due to this pattern, the search term passed into addMatches will<br>
*always* match whatever came out of query() and so it is completely<br>
unecessary to check the value of the term passed into addMatches. at one<br>
point i put in some asserts to test this theory and they were never hit no<br>
matter what i tried to do.<br>
<br>
if this does work out, i'll change addMatches and addMatch to not take a<br>
QString at all. that will require changing all the runners, however, so i'd<br>
like to get this patch peer reviewed, tested and in svn before going down<br>
that path.<br>
<br>
the attached patch implements the above, and shows nicely how the shared dptr<br>
approach can help us get RunnerMatch as clock to lockless as possible.<br>
<br>
i've been running with it since yesterday and things seem to behave nicely.<br>
<font color="#888888"><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>
</font><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>