[Kde-pim] KMail completion spams nepomuk, which isn't parallelized

David Faure faure at kde.org
Fri Jul 6 16:46:38 BST 2012


Typing 10 letters in the kmail composer "To" field, leads to 10 autocompletion nepomuk queries, 
all of which create a different thread in the nepomukqueryservice, and they pile up, each waiting
for the previous one to finish, because they use the same mutex-protected socket for the
connection to virtuoso...

All the threads in `nepomukservicestub nepomukqueryservice` have this bt:

Thread 5 (Thread 0x7fffea00e700 (LWP 23920)):
#0  0x00007ffff4361cd9 in syscall () from /lib64/libc.so.6                                          
#1  0x00007ffff78f1652 in _q_futex (addr=0x7fffe4003220, op=0, val=2, timeout=0x0, addr2=0x0, val2=0) at thread/qmutex_unix.cpp:99
#2  0x00007ffff78f170a in QMutexPrivate::wait (this=0x7fffe4003220, timeout=-1) at thread/qmutex_unix.cpp:113
#3  0x00007ffff78ebe2a in QMutex::lock (this=0x7fffe4003038) at thread/qmutex.cpp:164
#4  0x00007ffff0440b56 in Soprano::Socket::lock (this=0x7fffe4003020) at /d/kde/src/4/soprano/client/socket.cpp:117
#5  0x00007ffff0441217 in Soprano::SocketStream::SocketStream (this=0x7fffea00d8a0, dev=0x7fffe4003020) at /d/kde/src/4/soprano/client/socketstream.cpp:36
#6  0x00007ffff0444f13 in Soprano::Client::ClientConnection::executeQuery (this=0x7fffe40035c0, modelId=343926100, query="select distinct ?email ?fullname where { ?r a nco:Contact . ?r nco:hasEmailAddress ?v .  ?v nco:emailAddress ?email . { FILTER regex( str(?email), \"\\\\bfaure\", \"i\") . ?r nco:fullname ?fullname } union "..., type=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at /d/kde/src/4/soprano/client/clientconnection.cpp:227
#7  0x00007ffff04476b7 in Soprano::Client::ClientModel::executeQuery (this=0x7fffe4003110, query="select distinct ?email ?fullname where { ?r a nco:Contact . ?r nco:hasEmailAddress ?v .  ?v nco:emailAddress ?email . { FILTER regex( str(?email), \"\\\\bfaure\", \"i\") . ?r nco:fullname ?fullname } union "..., language=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at /d/kde/src/4/soprano/client/clientmodel.cpp:101
#8  0x00007ffff60b631a in Nepomuk2::MainModel::executeQuery (this=0x7fffe4002d60, query="select distinct ?email ?fullname where { ?r a nco:Contact . ?r nco:hasEmailAddress ?v .  ?v nco:emailAddress ?email . { FILTER regex( str(?email), \"\\\\bfaure\", \"i\") . ?r nco:fullname ?fullname } union "..., language=Soprano::Query::QueryLanguageSparql, userQueryLanguage="") at /d/kde/src/4/nepomuk-core/libnepomukcore/resource/nepomukmainmodel.cpp:182
#9  0x00007fffeba31eee in Nepomuk2::Query::SearchRunnable::run (this=0x7a4620) at /d/kde/src/4/nepomuk-core/services/queryservice/searchrunnable.cpp:89
#10 0x00007ffff78e12fd in QThreadPoolThread::run (this=0x7a4960) at concurrent/qthreadpool.cpp:107
#11 0x00007ffff78f1f28 in QThreadPrivate::start (arg=0x7a4960) at thread/qthread_unix.cpp:307
#12 0x00007ffff7631f05 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff436510d in clone () from /lib64/libc.so.6

Thread 5 is looking for "faure"
Thread 4 is looking for "faur"
Thread 3 is looking for "fau"
Guess what I was typing ;)
Thread 2 is doing another query, but also waiting on the socket.
Thread 1 is in the event loop.

Is there a way to cancel such queries? Surely kmail should abort the running query when making another one,
it makes no sense to keep looking for "foo" when the user has replaced it with "bar".

The other conclusion from this is... what's the point in having threads in the query service
if they all wait on each other anyway due to the shared socket?
This can lead to a very long delay, e.g. when sending an email (again), because it has
to wait for all the previous queries to finish first.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list