killing runners

[Jordi Polo]

I'm splitting my last emails to make them more easily understandable.

We have the problem of running runners (not in queue, but running) that can
not be signalized to finish when a new query is launched and thus, they are
running on obsolete data. They are a bad thing (tm).

I am thinking about something like this:

- bool AbstractRunner::criticalSection,
AbstractRunner::setCriticalSection(bool)
setCriticalSection will be set to true when a critical section of the runner
is entered, so far, that sections will be when the runner is modifying the
SearchContext, as locks will be held.

- Implement FindMatchesJob::requestAbort as
 if (!m_runner->criticalSection())
{
    isFinished(true):
    emit(done)
}

I am not sure if this will be enough to make ThreadWeaver stop and delete
this job but I think it will.
The problem is that all the runners should be changed to use
setCriticalSection (true) where needed.
Also a bad written runner can be killed in a critical section leading to a
held lock.


-- 
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/44d8a6f3/attachment.html