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