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

List:       kfm-devel
Subject:    Re: some thoughts on libkio
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-12-07 12:11:19
[Download RAW message or body]

On Mon, 06 Dec 1999, Stephan Kulow wrote:
> Simon Hausmann wrote:
> > 
> > That means we will depend on a running server process in order to have a
> > working kiojob? (like with kfm)
> 
> No, the master slave should be restartable without notice. What I have
> in
> mind is:
> app asks dcopserver
> dcopserver asks kioslave (that's the slave without protocol specific
> knowledge)
> (kioslave may be started when not present)
> kioslave forks, the new process dlopens kio_file.la if it's the first
>   time invoked and waits for input by it's parent process
> the kioslave sends back a ticket to the app
> the app opens a socket (,crunches the address of it with the ticket) and
> sends
>   back to kioslave the address
> kioslave pipes to the process and this one contacts the application.
> 
> The application (in form of libkio) can get only one slave per protocol
> and can ask this one to fork itself for further requests. There the
> managing qualities of libkio come to work :)
> 
> I'm not sure if this is the best solution, but this is what I found when
> I thought about the problem :)

I would let the master slave do all the dlopening and forking. 
E.g: 
1) Request comes in via DCOP
2) dlopen library if not already done
3) create communication socket
4) fork, child uses the communication socket from step 3)
5) reply to application via DCOP  to use the communication socket from
step 3

The master slave would also be responsible for detecting the death of
childs and closing libraries when no longer in use.

I am not yet convinced that the savings are worth the trouble though.
Typically we have about 5 slaves around. It would mean that the startup
of 4 of those 5 would be somewhat faster and that we may win 4 x 400Kb
= 1.6Mb of memory.

Cheers,
Waldo

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