[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kio multithreading
From:       David Sweet <dsweet () kde ! org>
Date:       2000-12-31 23:43:32
[Download RAW message or body]

On Friday 29 December 2000 10:07, Waldo Bastian wrote:
> On Friday 29 December 2000 16:27, Thomas wrote:
[...]
> >
> > Is there a hard-coded maximum ??
>
> Yes and this is a design problem. The kio scheduler is able to schedule
> slaves to jobs. This works nice, e.g. you can create 50 jobs and then the
> scheduler will allocate 5 slaves that will handle these jobs.
>
> The problem starts when you have 5 long-lasting downloads going. The
> scheduler will not create more slaves but waits for one of the slaves that
> are busy to finish first.
>
> I can fix that problem by lifting the limit of 5, essentially putting the
> scheduler out of business, but that creates problems when you e.g.
> recursively copy a directory-tree, because then you suddenly get 200 slaves
> or so.
>
> So if anyone has an idea how to solve this I'm interested to hear it.

I have an idea:  Create two pools, one for short jobs and one for long jobs.  
Allow, say 10 short jobs (S) and 5 long (L) jobs.  Jobs should go into the L 
pool until they report their size and can be moved into S is appropriate.  
This way unspeicifed-length jobs are safely treated as if they were long.

A note about the definition of "long" and "short".  This should be based on 
the time to complete the job which depends on file size, hardware use, and 
possibly other things.  That means that each slave should decide what is long 
and what is short and be able to report that.

Anyway, with a system like this you could still web browse (S) while 
downloading the new KDE tar balls (L), for example.

Dave
-- 
Read and annotate _KDE_2.0_Development_ at Andamooka:
http://kde20development.andamooka.org/

[prev in list] [next in list] [prev in thread] [next in thread]