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

List:       kfm-devel
Subject:    Re: PATCH: Handing over of IO-slaves
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-10-30 23:08:43
[Download RAW message or body]

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....)

> * 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 ?
Isn't a "global bool" (process-wide) a problem, if multiple jobs are started
at the same time ?

> 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 ;)

> Some problems:
> * If the link is handled by an other but already running application, 
> KIO::Scheduler::checkSlaveOnHold() should be called. I guess I need to add 
> that to NetAccess somewhere.

... which brings me back to "why not always do this" ?

> * There is a race condition between publising the slave and requesting the 
> slave by the other application. It can be that the slave still has to connect 
> to klauncher when the other application checks for the slave. I think 
> publishSlaveOnHold should wait till the slave has connected itself to 
> klauncher somehow.

Yes, that sounds necessary....

> Please test. With this change it should be possible to simplify konq_run and 
> khtml_run as well I think.

Definitely. Much code will be factorized.

Thanks!
David.

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