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

List:       kde-core-devel
Subject:    Re: DCOP problems here, too
From:       Matthias Elter <elter () trolltech ! com>
Date:       2001-03-06 19:14:17
[Download RAW message or body]

On Tuesday 06 March 2001 19:10, David Faure wrote:
s it is exactly the problem I mentioned. The timer triggers a DCOP call
> > and sometimes "...I casually get kicker hangs..." this happens just in
> > the moment when it already is in a call. Freeze. Somebody should fix
> > KRun.
>
> But that's impossible... KRun is by definition asynchronous.
> If it was only via KIO, then we could indeed get rid of the timer (which
> predates the KIO era). But in some cases (for instance with helper
> protocols like mailto:, for which KRun has nothing to do), or more
> importantly for local files (where we use ::stat directly), init() emits
> signals (foundMimeType(), finished(), error() etc.).
> If this is directly called by the constructor, then the application will
> have had no time to connect to those signals, so nothing will work.
> That's why we have to have this single-shot timer, so that KRun starts
> "running" after the control has gone back to the application (to connect
> the signals).
>
> What are the OTHER solutions ?
>
> Starting to use our own bugfixed copy of ICE so that re-entrant calls work
> (according to Waldo) ?
>
> Implementing a flag or lock, so that KRun waits for the current DCOP call
> to terminate before making its own ? (In that case it would work, but for
> cases where A calls B which calls C, it would become a deadlock :(

Yes use a in_call flag and ignore the timer event if you are already in a 
call.

> No, I think the only solution is to allow simultaneous DCOP calls
> (i.e. re-entrancy at the ICE level).

There is a way to fix it on the dcop level. But this means that calls in a 
situation when the client already is in a call will simply return with an 
error.

Matthias

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