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

List:       kfm-devel
Subject:    Re: PATCH: Handing over of IO-slaves
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-10-30 23:23:20
[Download RAW message or body]

On Tuesday 30 October 2001 03:08 pm, David Faure wrote:
> On Mercredi 31 Octobre 2001 00:03, Waldo Bastian wrote:
> > The following patch makes it possible to hand over IO-Slaves from one
> > process to another.
>
> Woohoo ! It's Christmas ;)
>
> > There are two functions that you might be interested in:
> >
> > * KIO::Scheduler::publishSlaveOnHold()
> > After an IO-slave has been put on hold by calling putSlaveOnHold(),
> > publishSlaveOnHold() will send the slave back to klauncher, making it
> > available for other processes as well.
>
> Sounds good.
> (for a more OO API, one could have preferred job->publishSlave() after
> job->putOnHold(), though....)

The job is  no more after you put it on hold.

> > * KIO::Scheduler::checkSlaveOnHold(bool b)
> > Calling this function before starting a "GET" job, will, once the GET job
> > starts, query klauncher whether a slave has been put on hold for it. The
> > default is "true" at startup and it is reset to false after each GET
> > request.
>
> What's the point in that one ? Why shouldn't all jobs look for a slave on
> hold before launching a new one ?

I don't want to add an extra dcop-call to klauncher for every job.

> Isn't a "global bool" (process-wide) a problem, if multiple jobs are
> started at the same time ?

Maybe with threads, but otherwise you would set the flag and create the job, 
and not much can happen in between that.

> > Together with some changes to KRun, this means that you can now click on
> > a link in an application and that determining the mimetype (which happens
> > in the application) and actually reading the contents (which happens in
> > the application that gets started for the mimetype) is handled by a
> > single GET request and a single io-slave.
>
> Yup, that's great.
> (Thinking of the 150 bug reports about wrong answers to HTTP HEAD requests
> ;)

:-)

Cheers,
Waldo

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