[Panel-devel] Multithreaded krunner

Ryan Bitanga ephebiphobic at gmail.com
Sat Nov 17 10:36:22 CET 2007


Hey everyone,

Here's the patch against the last time I svn up'd (r737082). Sorry for
the delay, school kinda got in the way. And if I had only paid a
little more attention to the threadweaver API, I could have avoided
several unproductive days pinpointing the exact reasons for crashes
and could've released this a week ago.

Anyway, the multithreading-related changes are:
SearchAction:
- Remove inheritance from QAction
- Implement data(), setData(), icon(), setIcon(), text(), setText(),
isEnabled(), setEnabled() methods in SearchAction
  Though i seriously doubt isEnabled and setEnabled are that useful.

SearchContext:
- Add a QReadWriteLock
- Make functions thread safe
- Add a matchesChanged() signal
- Separate code related to setting the SearchContext type (remnant of
a previous attempt to run this code in a separate thread)

Runners:
- Change QActions to Plasma::SearchActions

Interface:
- Use threadweaver classes
- Add a delay before updating matches so just in case multiple runners
return results, the list only has to be updated once

Notes for writing future runners:
- Use Plasma::SearchAction instead of QAction
- Don't create QObjects that are children of objects from different
threads (such as the runner)
- Follow the others reminders in the Qt4 documentation about multithreading.

Changes I snuck in:
- change canBeConfigured() to isConfigurable() for the sake of API consistency
- add a whitelist to loadRunners() so users can selectively load
runner plug-ins in the future

Possible changes:
- Move code from determineType() back into setSearchTerm() to avoid
the penalty of calling another lockForWrite().
- Or bring back the old KUriFilter code and run determineType() in a
separate thread by demand. Also entails adding a requiresContextType()
method to AbstractRunner so the interface can schedule a job to
determine if SearchContext::determineType() needs to be run. (Still
have the code for this).

Possible problems:
- KRunner may not be responsive if the query is changed while the
match method of a slow runner is being executed by threadweaver.
  This is because ThreadWeaver doesn't abort jobs that are currently
being run and aborting jobs requires the implementers of runners to
have knowledge about ThreadWeaver jobs.
- Autocomplete sometimes makes it unresponsive for a few seconds. This
is a direct consequence of the problem stated above. ThreadWeaver
waits a few milliseconds then wakes up to monitor the status of the
job while the GUI thread is suspended the entire time.

Constructive criticism and comments are welcome :)

P.S. I noticed aseigo committed a number of changes to interface.cpp
yesterday. I'll merge my changes and post an updated patch shortly.

Cheers,
Ryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krunner.diff.bz2
Type: application/x-bzip2
Size: 5858 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071117/7fe42065/attachment-0001.bz2 


More information about the Panel-devel mailing list