[Panel-devel] Multithreaded krunner

[Ryan Bitanga]

On Dec 2, 2007 3:31 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday 02 December 2007, Ryan Bitanga wrote:
> > On Dec 2, 2007 1:44 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > > On Saturday 01 December 2007, Aaron J. Seigo wrote:
> > > > wonderful =) please commit and i'll make the above additional
> > > > improvements. thanks =)
> > >
> > > hm.. there seems to be some deadlocks still in there. with rapid type and
> > > ctrl-u'ing i can get krunner to either completely lock (ui repaints, but
> > > all interaction, including typing or clicking on buttons, is gone) or
> > > just not get any matches (so you type and no matches show up)...
> > >
> > > i'll try and investigate this tomorrow.
> >
> > How long does it lock?
>
> full freeze is permanent and i have to kill krunner; when it doesn't come back
> with matches (much easier to trigger) i have to hide then re-show the
> interface.
>
Haven't gotten it to freeze yet. The GUI thread is only blocked during
addStringCompletion(), addStringCompletions(), determineType(),
resetInterface(), and addMatches(). One of those must be causing your
freezes.

> > The most I've experienced is a fraction of a
> > second which is an improvement over the previous one that took around
> > 5 seconds at times. I haven't dug deep but the GUI thread is only
> > blocked when matches are updated.
>
> yeah, it's not due to matches being updated ... i'm getting full on
> no-matches-getting-returned issues.
>
> how to trigger:
>
> * type a word that has matches
> * quickly press ctrl-u to clear the line edit
> * repeat
>
> if you do it fast enough eventually it will just stop returning matches =/

I couldn't resist bug hunting and I found out that the reason krunner
occasionally failed to produce results is because it's busy running
jobs for outdated queries. Threadweaver defaults to 4 threads and in
all of the times I got krunner to not produce results, all four
threads were busy running the Search runner for different queries.
Attached is a tiny portion of the output with ThreadWeaver debugging
turned on. When the query is changed but no results are shown,
threadweaver only reports dequeueing the jobs and the enqueueing of
the job collection, but the jobs themselves are not enqueued and
executed. After several seconds, when one of the threads finishes
executing the code for search runner, krunner starts giving results.

Apparently, the "continue running match method and discard matches
when outdated" approach has the problem of allowing slow runners to
hog the CPU while not doing anything useful. It appears our choice
are: 1) add provisions for aborting within some runners as I explained
in an earlier e-mail, and 2) check ThreadWeaver to see if its busy,
and post a "Please wait" message if all threads are busy and no
results have been retrieved yet. With option 1, we can keep our
current framework and only add provisions for aborting so authors of
runners aren't forced to put isAborting() checks in their match
methods. In any case, the "no matches returned" problem is caused by
abusing krunner and _shouldn't_ happen with normal usage.

Cheers,
Ryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krunnertrace
Type: application/octet-stream
Size: 3907 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071202/caaab221/attachment.obj