Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Aaron J. Seigo]

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.

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

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

-- 
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 Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090729/d58ede40/attachment-0001.sig