[PATCH] KIO::SlaveBase and the event loop
thiago at kde.org
Fri Jul 18 03:24:59 BST 2008
Roland Harnau wrote:
>2008/7/16, Thiago Macieira <thiago at kde.org>:
>> Also note that all ioslaves are forks from kdeinit. All the main
>> libraries are already loaded and there's no D-Bus connection -- it's
>> only a plain, simple Unix socket that connects to the application.
>But if an application "owns" n slaves, there are also n socket
>connections and the data has to be processed by the application's main
>thread. This is perhaps a problem if n is a "big" number. And the
>creation of slaves in KIO::Slave::createSlave includes some D-Bus
>talk unless KDE_FORK_SLAVES is set. In principle forking kdeinit
>should be faster than using QProcess. In this regard the result of
>calling KIO::Slave::createSlave 20 times in a row is quite
>interesting: If klauncher/kdeinit is used, it takes ~2.6 seconds on my
>eeePC, whereas with set KDE_FORK_SLAVES it takes only ~1.4 seconds.
Then I suggest you profile the ioslave creation. I can't see why it should
take 130 milliseconds to complete. The average round-trip for a short
D-Bus message using QtDBus is less than a millisecond.
Anyways, the point Ingo tried to make is: you provided us with a number
(2.6 seconds) for normal ioslaves. You have not proven that threads are
better. And if you don't find out why, in specific, kdeinit forked
ioslaves are slow, there's no guarantee that threads will be any
>>>> If we used threads, a badly behaving ioslave could crash Konqueror,
>>>> KWrite, Kile, KWord, anything that uses KIO. Right now, it crashes
>>>> on its own and its name is pointed out.
>> The difference to Plasmoids here is that a badly behaving plasmoid
>> would crash plasma. A badly behaving ioslave plugin thread would crash
>> any and all KDE applications.
>If slaves are per-application (e.g. by changing/subclassing
>KIO::Slave for certain protocols) I don't see any difference.
You're missing the point. There are no applications that load Plasmoids,
other than Plasma (even if you consider that Amarok will use libplasma,
it's using the infrastructure, not the actual Plasmoids). However, ALL
non-trivial KDE applications use ioslaves, to an extent or another.
If someone installed a crashy Plasmoid, he'd have Plasma crashing. And
until he identified the problem, he could use KDE 3 or another DE, while
still maintaining his usual applications.
However, if you install a crashy ioslave, ALL KDE applications could
potentially start crashing and being wholly unable to work. In that case,
switching to another DE won't help, because you can't use your usual
applications. For example, I don't suppose people keep Mozilla
Thunderbird configured for their email accounts just in case KMail starts
crashing, nor Firefox's password database if Konq stops working.
>As Plasma applets are essentially QGraphicItems this seems not
>possible anymore. After all, Plasma is pretty stable now and I don't
>see even remotely a reason for all the disadvantages of an
And I can say the same of ioslaves: they are pretty fast now and I don't
see a reason for all the disadvantages of an in-process threaded
If neither you nor anyone else is willing to rewrite the basic ioslaves
(file and http, at the very least) in a thread-safe manner and provide
the profiling to prove your case, this point is moot.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel