On Tuesday 06 March 2001 17:49, Matthias Elter wrote:
> On Tuesday 06 March 2001 18:15, Carsten Pfeiffer wrote:
> > Hi,
> >
> > I dunno when the problem started, but since a while I casually get kicker
> > hangs, when e.g. launching konqueror. I just attached to it and got a
> > backtrace:
> >
> > #2  0x40bbd31a in _IceTransRead () from /usr/X11R6/lib/libICE.so.6
> > #3  0x40bb3a7d in _IceRead () from /usr/X11R6/lib/libICE.so.6
> > #4  0x40bb3fbe in IceProcessMessages () from /usr/X11R6/lib/libICE.so.6
> > #5  0x4002f80e in DCOPClient::callInternal () from
> > /opt/kde2/lib/libDCOP.so.1
> > #6  0x4002f413 in DCOPClient::call () from /opt/kde2/lib/libDCOP.so.1
> > #7  0x404d35ee in startServiceInternal () from
> > /opt/kde2/lib/libkdecore.so.3
> > #8  0x404d418c in KApplication::startServiceByDesktopPath ()
> >    from /opt/kde2/lib/libkdecore.so.3
> > #9  0x402119fa in Observer::Observer () from /opt/kde2/lib/libkio.so.3
> > #10 0x401c9ae3 in KIO::Job::Job () from /opt/kde2/lib/libkio.so.3
> > #11 0x401ca772 in KIO::SimpleJob::SimpleJob () from
> > /opt/kde2/lib/libkio.so.3
> > #12 0x401cda60 in KIO::TransferJob::TransferJob ()
> >    from /opt/kde2/lib/libkio.so.3
> > #13 0x401d1289 in KIO::MimetypeJob::MimetypeJob ()
> >    from /opt/kde2/lib/libkio.so.3
> > #14 0x401d1738 in KIO::mimetype () from /opt/kde2/lib/libkio.so.3
> > #15 0x40161632 in KRun::scanFile () from /opt/kde2/lib/libksycoca.so.3
> > #16 0x40160b88 in KRun::init () from /opt/kde2/lib/libksycoca.so.3
> > #17 0x40161786 in KRun::slotTimeout () from /opt/kde2/lib/libksycoca.so.3
> > #18 0x4076a8ce in QObject::activate_signal ()
> >    from /home/gis/src/qt/lib/libqt.so.2
> > #19 0x407bccb4 in QTimer::timeout () from /home/gis/src/qt/lib/libqt.so.2
> >
> > Restarting kdeinit cures the problem, i.e. kicker reacts again.
> >
> > Is that the problem Matthias mentioned not so long ago, a DCOP call being
> > activated by a timer?
> 
> Yes 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 :(

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

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today