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

List:       kde-core-devel
Subject:    Re: kded
From:       Steffen Hansen <stefh () mip ! sdu ! dk>
Date:       1999-07-21 15:42:27
[Download RAW message or body]

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       

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