Sharing SearchContext
Jordi Polo
mumismo at gmail.com
Mon Apr 28 03:23:06 CEST 2008
Right now we have the concept of global context and the concept of local
context.
runners copy the global context in a local context, work with it and when
finished, use a SearchContext::addMatchesTo(SeachContext ) to add the
matches to the global shared context.
This means copies here and there, to avoid that, we can share data.
If we try to have shared 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).
So SearchContext will use internally a QExplicitilySharedDataPointer and I
think there is no need to write a copy constructor but if it does I guess it
will be like:
SearchContext::SearchContext(const SearchContext &other, QObject *parent)
: QObject(parent),
d(new Private(Shared))
{
other.d->lockForRead();
//d=other.d;
other.d->unlock
}
--
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/e9104ef4/attachment.html
More information about the Panel-devel
mailing list