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

List:       kde-core-devel
Subject:    Re: kded
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-07-22 14:22:49
[Download RAW message or body]

On Wed, 21 Jul 1999, Steffen Hansen wrote:

> On Tue, 20 Jul 1999, Simon Hausmann wrote:
> 
> > Hello.
> > 
> > The promised recovery mechanism for kded works now, but there are two
> > problems:
> > 
> > 1) It works only for me, because I reverted the KProcess patch from last
> >    week (as discussed on irc) . Anyone able to fix the fix? Or should we
> >    completely revert it?
> 
> My test-app that activates konqy through kded also sometimes hangs when
> invoking methods on konqy. I wonder if this is the KProcess bug again, or
> a race in KActivaor.

Don't blame KActivator ;-) , it's much too simple to do anything evil ;-))

Sounds like something with the mediators..

Very strange indeed, I never had this problem.

> > 2) The recover stuff makes things (kded code) look *really* ugly :-(
> >    I have to query for the service corba objects (KDED::Trader, ...) upon
> >    *every* invokation. This looks ugly and is also slow.
> 
> Hmm. The only nice way to do this is to catch exceptions, examine if
> kded is dead, and restart it.

That's what I'm actually doing, but that ugly proxy-release-problem made
everything look ugly (slow!) :-(

I can send you a diff of my changes so you can have a look at it (I think
comitting will just make ppl see what ugly code I write ;-}

> >    The reason for this is that I can't release a proxy of a dead remote
> >    object.
> >   
> >    code like 
> >    
> >      m_vTrader = KDED::Trader::_duplicate( the_trader_of_the_new_kded )
> > 
> >    simply crashed somehwere in mico. I have no clue why.
> > 
> >    So I had to remove this member variable and query for it every time :-(
> 
> This isn't really acceptable. The mico bug needs to be fixed instead.

Unfortunately I can't locate it :-(

Perhaps you can report it/ask on mico-devel? (I'm not subscribed anymore)

> > So in somehow I get the impression that CORBA for IPC between
> > client<->kded-server is a bad thing. See the CORBA interfaces of the
> > Trader/Activator of kded and you know why: It's simply ugly IMHO.
> > And in somehow I feel like we misuse CORBA.
> 
> Why is the Trader/Activator interfaces ugly? It least KDED::Activator
> seems nice and minimal to me. KDED::Trader is a bit large, but that only
> due to the Property stuff (that's needed for profiles, isn't it?)

Well, ok, Activator is ok with me, but the Trader is a real ugly beast
IMO.

There are two problems behinds this interface

a) properties
   We definitely need KService properties, but writing support for this in
   IDL is hard IMO. I once tried with unions and such (as you can see in
   kded.idl), but this makes the idl compiler create loooots of code (and
   I had to raise up the template depth to a rather high number to compile
   at all) . Well, ok, the last time I tried was when we were still using
   normal STL, rather than ministl now.
   However even if we manage it to define a complete KService in IDL we
   still have the second problem:

b) performance
   Using CService & friends is slloooooooooowww. And queries to the trader
   have to be as fast as possible IMHO.

I hacked around these two problems pretty ugly: See the awful
StreamedOfferList stuff? and fastQuery?

I had to put the KService stuff into a QTextStream, which is transformed
into the sequence defined in kded.idl. The same process reverted on the
client side then.

That's what I meant with "misuse" of CORBA, and that's why I was looking
for a different way of IPC between kded-server and the clients.

Perhaps you have a good idea to solve these two problems in a fast
approach, still using IDL?

> > I wonder whether we should consider switching to plain socket
> > communication or shared memory (difficult) ? It's faster and perhaps
> > creates less trouble to recover from a crash.
> > 
> > The client interface would not be touched in any way, so we stay source
> > (perhaps even binary) compatible.
> 
> The CORBA interfaces for Trader/Activator _are_ the client interfaces. The
> KTrader/KActivator C++ interfaces are only for convenience (although i
> like them very much :)

As long as we are only able to put the recover mechanism behind these
C++ interfaces (try{}catch{}...) I don' think using the CORBA equivalents
is a good idea.

> > And: We would not loose any functionality, except that kded's services
> > can't be used via CORBA anymore, but the c++ interface are much better
> > IMHO anyway :-))
> 
> The CORBA idea is only really useful if it is used all over the place.

I agree 100%

> Either we drop CORBA, or we use it. If we can come up with a clever way
> for kded to know that it is recovering from a crash, it might be possible
> for it to use the same IOR and address as before. This way clients that
> dont perform invokations just when the crash occurs wont suspect anything
> :)

I guess POA objectkey magic is the key to this approach, right? ;-)

> The check for a running kded must be better than it is now. My idea is:
> In addition to the root X Property, we must have a (hidden) window opened
> by kded. The window ID from that window is adder to the prop. too. This
> way a second kded can see, if this window is there. Then is reasons: "Hmm,
> if the root property is there, but the window is gone. Kded must have
> crashed". Then is can read the IOR from the prop. and do it's magic.
> 
> (To Simon: I am subscribed ;-)

Ok, sorry for the trouble :-)


Ciao,
 Simon

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