[PATCH] KIO::SlaveBase and the event loop

[Thiago Macieira]

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 
significantly faster.

>>>> 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
>out-of-process approach.

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 
approach.

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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080717/bdbf10c1/attachment.sig>