<br><br><div class="gmail_quote">2008/4/28 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 Sunday 27 April 2008, Jordi Polo wrote:<br>
> Also a bad written runner can be killed in a critical section leading to a<br>
> held lock.<br>
<br>
</div>so it's potentially dangerous and makes it more difficult to write runners.<br>
<br>
what's the upside to this again?</blockquote><div><br>If we end up with a SearchContext that detach() when deleting matches for instance, we have the problem that when a new query comes, we potentially still have SearchContext around. The global context is resetted, as the reference count is greater than 1 will create a copy ...<br>
<br>If we don't use detach, as "term" must be provide to add a match, old matches will not be added to new context, so the only problem I see is as we launch lots of runners for each typed letter, non-finishing runners can accumulate, fill the running slots and stall krunner. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
or rather: how much time are we spending waiting for useless runners blocking<br>
proper matches?</blockquote><div><br>The problem is that we can not know. We can not know how many runners will be wait in a dbus transation with a program or in a network operation. <br>We can not prevent them as they may be what the user really wanted anyway. <br>
<br>I don't know if there is a way to provide a maximum reply time to dbus (I insist on dbus because the xesam runner seems to hold on waiting on that when I stress krunner, that will need more testing thought)<br><br>
<br><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;"><br>
<br>
if signifcant, is there a way to prevent those runners from starting in the<br>
first place, or exiting quickly enough to not matter?<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>