Reusing of KIO slave instances

[Sebastian Trueg]

Did I understand correctly from reading the thread: except for the
changes in job.cpp you commited your patch? I.e. maxInstancesPerHost
supprot is already implemented if an app uses the scheduler?
So what I would test is the part of the patch that potentially leads to
dead-locks in file_copy and friends?

If so, yes, of course I will test that one.
Cheers,
Sebastian

Dawit A. wrote:
> 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...
> 
> 
> 
> 
> 
> 
> 
> 
> 
>