From kde-core-devel Wed Nov 18 20:59:26 2009 From: "Dawit A." Date: Wed, 18 Nov 2009 20:59:26 +0000 To: kde-core-devel Subject: Re: Reusing of KIO slave instances Message-Id: <200911181559.26609.adawit () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125857854228457 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...