Reusing of KIO slave instances
Dawit A.
adawit at kde.org
Wed Nov 18 20:59:26 GMT 2009
On Wednesday 18 November 2009 14:34:41 Sebastian Trueg wrote:
> I have a problem with my Nepomuk kio slaves: it seems that existing
> instances are not reused but Dolphin spawns a new instance for each
> request, even subfolders. Is that normal? Is that something I can fix on
> my end? Is it something I can influence at all?
>
> Because with a single Dolphin instance I suddenly get ten or more
> timeline:/ and nepomuksearch:/ instances.
Bascially the default behavior of KIO is to create an ioslave for each request
unless there is already an idle ioslave that can be used to handle the
request. By default there is no limit on the number of ioslaves that will be
created to handle requests, i.e. no request queueing...
The down side of course is issues like the one you raised here. If 40 requests
are made by the client using KIO::get/post/etc in a short period of time, then
an equal number of ioslaves will be created because none of them will be idle
for reuse and there is no "limit" on the number of ioslaves to be spawned. If
the client does not want that to happe, then it has to explicitly call
KIO::Scheduler::scheduleJob(...) after calling KIO::get/post/etc. Ofcourse,
this is almost never done by any client application.
The question people raise when I give the above short explanation of how KIO
was designed to work long long time ago is, why is not the scheduling done by
default ?? I cannot answer that question, but there have been discussions
about doing just that. You can see the details in the link below:
http://lists.kde.org/?t=125149495900004&r=1&w=2 and
http://lists.kde.org/?t=124531188100002&r=1&w=2
As seen in the above links, there were a few proposed patches to change the
default KIO behavior to schedule (queue) requests, but due to concerns that
such changes will cause deadlock conditions, the patch went nowhere...
Having said all that if you are willing to test a newer version of the patch I
proposed in the first link above with potential fixes for the dead lock
conditions, then I can try to port the patch to trunk. I am currently using
this patch with KDE 4.3 on my own machine and works fine for me...
More information about the kde-core-devel
mailing list