<br>About the last ideas on krunner internals:<br><br>If we try to have sharing of data, we do not need to detach from the shared object when:<br>-reading<br clear="all">-Adding matches<br>-Adding completions<br><br>We need to detach when:<br>
- 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.<br>
- 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. <br>
<br>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) <br><br><br>About the idea of manage completions as SearchMatch::CompletionMatch:<br>
<br>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:<br>
- 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 ...<br>
- 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. <br>
<br><br>Killing runners. <br>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).<br>
<br>I am thinking about something like this:<br>- bool AbstractRunner::criticalSection, AbstractRunner::setCriticalSection(bool) <br>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. <br>
<br>- Implement FindMatchesJob as requestAbort as <br> if (!m_runner->criticalSection())<br>{<br> isFinished(true):<br> emit(done)<br>}<br><br>I am not sure if this will be enough to make ThreadWeaver stop and delete this job but I think it will. <br>
<br>I'm waitting for thoughts about these issues before go and change it. <br><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>