From kde-core-devel Wed Jul 21 15:42:27 1999 From: Steffen Hansen Date: Wed, 21 Jul 1999 15:42:27 +0000 To: kde-core-devel Subject: Re: kded X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93257166415561 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. > 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. > 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. > Result: It works, but it's ugly. And we have to solve the KProcess thing > first before I can commit. The KProcess bug only shows up, when kded refuses to start, doesn't it? Please commit, so we can have a look at it. > 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?) > 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 :) > 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. 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 :) 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 ;-) greetings, -- Steffen Hansen email: stefh@mip.sdu.dk, stefh@imada.sdu.dk, hansen@kde.org URL: http://www.mip.sdu.dk/~stefh