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

[Lailah]

In what system is happening this?  I didn't see that on my Fedora  (17,
64-bits, KDE 4.8).

Regards,
Lailah

El vie, 06-07-2012 a las 17:46 +0200, David Faure escribió: 

> 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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120708/aa7ce3dd/attachment.sig>
-------------- next part --------------
_______________________________________________
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/