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

List:       kde-core-devel
Subject:    Re: some thoughts on libkio
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-12-07 0:09:09
[Download RAW message or body]

Cristian Tibirna wrote:
> 
> On Mon, 6 Dec 1999, Stephan Kulow wrote:
> 
> > Cristian Tibirna wrote:
> > >
> > > On Mon, 6 Dec 1999, Stephan Kulow wrote:
> > >
> > > > Simon Hausmann wrote:
> > > > >
> > > > > So if I understood Waldo's mail correctly, then each KIOJob tries to
> > > > > connect to that one running kio_slave daemon process (or start it on
> > > > > demand, if not available/running) . That kio_slave process then forks and
> > > > > loads the protocol implementation as shared library.
> > > > >
> > > > > (hmm, I guess I must have misunderstood sth., as otherwise the current
> > > > > concept looks more lightweight to me (note that the current kioslaves
> > > > > don't create a [Q/K]Application object) .
> > > >
> > > > They don't need to in Waldo's concept either.
> > > >
> > >
> > > Or perhaps, instead of a daemod for each type of slave, use the inetd
> > > concept?
> > >
> > Which basicly means starting a new instance for each call, right?
> > That's exactly what Waldo wants to avoid as new instances cost more
> > memory
> > than forking the same instance and changing only what needs to be
> > changed.
> >
> 
> True. Thanks for explaining.
> 
> While I think... OK! No! Using best of two approaches would perhaps be
> performance penalized. One inetd-like daemon (let's call it kio_sherrif
> :-) that would be able to spawn a slave when service is required, and
> communicate with that slave (and order it to fork) when supplem requests
> come, and slave already exists. Shut down the slave when all transactions
> ended (something like the now-mainstream garbage collection on objects).
> That would require dcop communication, hence could prove to be speed
> impaired.
> 
> Anyways, having a dozen of kio daemons started and having perhaps 1 or 2
> used most of the time ... Or?
> 
Read my other posting - what you describe is going to happen :)

Greetings, Stephan

-- 
When your memory goes, forget it!

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