Issues with setupMatchSession/matchSessionComplete in RunnerManager

Ryan P. Bitanga ryan.bitanga at gmail.com
Wed Jul 29 19:06:18 CEST 2009


On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo<aseigo at kde.org> wrote:
> On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
>> Because we can launch a new query while jobs for an existing query are
>> still executing, any slots that are connected to prepare and teardown
>> have to be threadsafe.
>
> setup and teadrown should be called and executed from the main thread. queries
> should not be started until those signals (and slots connected to them) have
> been executed. there should be no threading involved at all at this point.
>

This means that while a query is executing, we can't emit the signals.
Calling matchSessionComplete in the hide event of KRunnerDialog isn't
safe in this case, so I think the best place to do this would be in
the destructor of FindMatchesJob. We'd check if the queue is empty,
and if it is then we can emit the teardown signal.

>> Another issue is that teardown is currently only emitted when the
>> dialog is hidden. I think the assumption was that there would be a one
>> to one correspondence between emissions of prepare and teardown.
>> However, with the current implementation, prepare will most likely be
>> emitted several more times than teardown.
>
> no, they are paired.
Yep, as noted in a previous e-mail, my bad.

>> or we could emit teardown prior to launching a new query. Say in
>
> there'd be no point to these signals at all then and runners would just do all
> their data gathering in (or just before) match(). that would be too slow. the
> point of these signals is to do the setup and teardown as rarely as possible,
> but also only when the data will be used.
>
Agreed, but the use case that came to mind while I was writing this
e-mail is that of the window runner. It caches the data once a query
is launched but the data may become invalid while the dialog is open
(e.g. an application is launched/closed while the dialog is open). But
this is an issue addressable in the runner implementation.


More information about the Plasma-devel mailing list