From kde-core-devel Thu Jul 22 14:22:49 1999 From: Simon Hausmann Date: Thu, 22 Jul 1999 14:22:49 +0000 To: kde-core-devel Subject: Re: kded X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93265916926858 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