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

List:       kde-core-devel
Subject:    Re: KIOSlaves
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-01-20 21:45:55
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Thu, 20 Jan 2000, David Faure wrote:
> > > > What needs to be changed in the API between KIOJob and
> > > > Application?
> > >
> > > In general: no reuse of KIOJob. a KIOJob should be _one_ job, not
> > > thousands.
> >
> > This would sound right, but isn't that a problem for keeping e.g.
> > FTP connections between requests ? That's why we have a pool
> > currently, right ? Or do we want to have a pool of connections on one
> > hand, and one-shot jobs on the other, the jobs taking a connection in
> > the pool ? This would solve the problem, right ?
> 
> The old slaves already had that. The "pool of connections" is
> represented by the pool of io-slaves. When a new job is created we look
> for an io-slave with a (possibly) matching connection.
> 
> > > The current kiojob is not the way it should be, it's just the way
> > > it happened to be. For example Lars demanded that you can issue
> > > several jobs at the same time without caring and giving priorities
> > > on the importance on the jobs (the stylesheet should be there
> > > before the images). This is a very important demand and I would
> > > expect something like this from a good IO-lib.
> > > But in the current KIOJob this wouldn't be possible without major
> > > hacks.
> 
> Does Lars has an idea how to implement this? I can imaging two ways:
> * Queue requests without actually starting them before all higher
> priority requests have been finished. (This is easy)
> * Throttle, e.g. tell an IO-slave not to receive any data or to receive
> not more than XX bytes/sec. (This sounds difficult)
> 
Yes, we queue them and start a timer to actually schedule them. If we
start, we know how many jobs we have to work on, how many connections
we can open at the same time and which priorities we have to care of.
This should be quite copy&paste from a SMP unix kernel ;-)

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

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