more on krunner internals

[Jordi Polo]

About the last ideas on krunner internals:

If we try to have sharing of data, we do not need to detach from the shared
object when:
-reading
-Adding matches
-Adding completions

We need to detach when:
- modifying the term. Which modifies the type and mime. And surely will
render matches and completions obsolete. So, instead of making a context
from other context it will be better just to initialize an unrelated
context. Modified term means a new context so we don't support detaching in
that case.
- deleting/clearing matches or completions. One context will not delete
other context matches. So what we want is to clear one given context
matches. Or what is the same: create a new context with already given term,
type and mime. Create a copy constructor that copies that info and
initialized a private clear matches /completions lists.

So basically,  detach can be avoided. We can always context1.addMatches(
context2.matches()) if it is needed to add matches from any new context to
an older one. (addMatchesTo will be deleted also)


About the idea of manage completions as SearchMatch::CompletionMatch:

As the GUIs will likely receive matches in bulks. It is inefficient and
redundant between GUIs to make them search the list for completions, display
them and  delete them of the matches list if needed (note that generally
completions and other mathes will have different GUI representations so they
will likely be distinguished). Some options:
- matches() accepts as parameter the type of match you want (can be or'ed or
left black for all the matches), so we avoid every GUI implementing this.
Note that the implementation of this method would be create a sublist
(comparing the type() or each entry) from the list and return. Not specially
fast ...
- Internally have 2 matches lists, one with completions and one with
everything else.  We can provide the above method anyway but in the likely
case of retrieving completions or in the case of retrieving the others, no
sublist is done.


Killing runners.
We have the problem of running runners (not in queue, just running) that can
not be signalized to finish when a new query is lauched and thus, they
become obsolete. 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 as 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.

I'm waitting for thoughts about these issues before go and change it.

-- 
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/20080427/722c21a2/attachment.html