fewer locks in RunnerContext

Jordi Polo mumismo at gmail.com
Thu May 8 03:30:12 CEST 2008


So basically making a copy of a RunnerContext and making a new RunnerContext
is equivalent?

In reset(), if the ResetContext reference count is not greater than 1,
detach will do nothing, we need to really clean term and friends there.

Right now the "term" in addMatch and addMatches is what protects from
runners running on old RunnerContext adding matches to the new
RunnerContext.
As discussed, we can clean the jobs queue but no mechanism is in place to
kill currently running runners, if they take a long time (and this is the
kind of thing with the potential of happening only in some circunstances of
some systems) they will be running and will complete when we already have a
new RunnerContext (user typed a new letter), right now, they present "term"
as the credential of what they are working on, so old matches can not be
added to new contexts.


2008/5/8 Aaron J. Seigo <aseigo at kde.org>:

> hi all..
>
> the data members of RunnerContext are now read-only for all intents and
> purposes: when the query term is set, the data is first detached creating
> a
> new set of data members to operate on. the RunnerContext API enforces this
> pattern.
>
> this means that we *should* be able to get rid of a number of locks
> completely, such as the read lock in query() -> QString is reentrant, the
> data is never being written to ... so no lock is needed.
>
> really, the only thing we need to lock aggressively is access to matches
> list.
>
> moreover, due to this pattern, the search term passed into addMatches will
> *always* match whatever came out of query() and so it is completely
> unecessary to check the value of the term passed into addMatches. at one
> point i put in some asserts to test this theory and they were never hit no
> matter what i tried to do.
>
> if this does work out, i'll change addMatches and addMatch to not take a
> QString at all. that will require changing all the runners, however, so
> i'd
> like to get this patch peer reviewed, tested and in svn before going down
> that path.
>
> the attached patch implements the above, and shows nicely how the shared
> dptr
> approach can help us get RunnerMatch as clock to lockless as possible.
>
> i've been running with it since yesterday and things seem to behave
> nicely.
>
> --
> 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 Trolltech
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
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/20080508/9d45aa52/attachment.html 


More information about the Panel-devel mailing list