killing runners

[Jordi Polo]

2008/4/28 Aaron J. Seigo <aseigo at kde.org>:

> On Sunday 27 April 2008, Jordi Polo wrote:
> > Also a bad written runner can be killed in a critical section leading to
> a
> > held lock.
>
> so it's potentially dangerous and makes it more difficult to write
> runners.
>
> what's the upside to this again?


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

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.


>
>
> or rather: how much time are we spending waiting for useless runners
> blocking
> proper matches?


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.
We can not prevent them as they may be what the user really wanted anyway.

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)





>
> if signifcant, is there a way to prevent those runners from starting in
> the
> first place, or exiting quickly enough to not matter?
>
> --
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080428/42950716/attachment.html