[PATCH] KIO::SlaveBase and the event loop
truthandprogress at googlemail.com
Tue Jul 15 19:09:10 BST 2008
2008/7/15, Thiago Macieira <thiago at kde.org>:
> Roland Harnau wrote:
>>Apropos ambitious plans: In the planning phase for KDE4 did you
>>consider to re-implement the IO slaves as threads? The process
>>creation cost including the D-Bus talk to klauncher seem quite high to
>>me, especially if Konqueror launches 20 or more of them.
> No. We've wanted separate processes for ioslaves for the whole time, since
> this improves stability. IOSlaves are add-on plugins (yay for multiple
> redundant buzzwords meaning the same thing!) that can come from many
> different sources. We can't really vouch for the stability of them.
This is equally true for Plasma applets, but they are nevertheless
in-process entities. It should be sufficient if the IO slaves
delivered with KDE are stable enough.
> Besides, we can't know if the code in the ioslaves is using a
> non-reentrant function or not.
Are there actually IO slaves in the KDE main packages using
non-reentrant (I assume this is Qt lingo, i.e. reentrant vs.
> 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.
Process isolation is not of much help much if the application becomes
dysfunctional because of misbehaving ioslaves or if the they still
hold system resources and compromise system stability. If
> As a future improvement, the launcher could detect a crashing ioslave and
> disable it temporarily.
gets implemented some day, the out-of-process approach would have at
least some justification. But the costs would be still high. There are
myriads of different processes using a non-negligible amount of system
resources, there are costs for process creation and IPC and it is
very difficult to manage them. And maybe this is one reason for the
still slow page loading in Konqueror at some sites.
More information about the kde-core-devel