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

List:       kfm-devel
Subject:    Re: some thoughts on libkio
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-12-07 12:43:20
[Download RAW message or body]

On Tue, 07 Dec 1999, Stephan Kulow wrote:
> Waldo Bastian wrote:
> > 
> > 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
> It basicly doesn't matter for the API and is only an internal to the
> io_daemon where the socket comes from. But in terms of responsobility
> and cleaness I believe that it's better to have only one protocol in
> one process.
> 
> > 
> > The master slave would also be responsible for detecting the death of
> > childs and closing libraries when no longer in use.
> That's the point - libraries are exactly bound to the lifetime of it's
> protocol daemons :)
> > 
> > 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.
> > 
> Well, as each app will start a slave when the file dialog uses libkio
> for everything, it's basicly a bad idea not to share them.

Right.  But even with the current design this is not a problem as the io-slaves
are shared with KIOSlavePool.

Regrads,
Dawit A.

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