timeouts in DCOP calls

[Lubos Lunak]

On Wednesday 29 of January 2003 18:18, Waldo Bastian wrote:
> On Wednesday 29 January 2003 15:25, Lubos Lunak wrote:
> >  Hello,
> >
> >  I had a look at the reported lockups with konqy preloading if some
> > (other) konqy freezes. First of all I figured preloading is innocent, it
> > cannot really block, unless kded freezes for some reason. It's the
> > reusing (for local browsing etc.).
> >
> >  Anyway, if you run e.g. the attache test app and browse it in kdcop, it
> > will work fine for 10 seconds when the app is still responding, and then
> > all calls will block until the app quits or responds. So I suppose DCOP
> > might need timeouts for calls waiting for an answer. See for example the
> > attached patch, which makes the timeout 2 seconds (only if useEventLoop
> > is false).
>
> Not locking up the application in the first place sounds like a better idea
> :)

 I'll forward your request to all KDE developers :).

>
> >  Now, the things I'm not sure about are how long the timeout should be,
> > if there should be a timeout for useEventLoop == true too, and what about
> > apps that don't use useEventLoop == true yet they don't really care if
> > they once a millenium block for few seconds because the other app is busy
> > at the moment.
> >
> >  Any ideas, comments?
>
> The http ioslaves make calls into the cookiejar that can block till the
> user has replied to the cookie dialog. That would break with a timeout. In
> general a dcop call can take an unspecified amount of time to get
> processed, depending on CPU, load etc. Just imposing an arbitrary limit of
> 2 seconds would make dcop calls rather unreliable.
>
> Maybe you could add a "useTimeout" flag.

 Another try, see attachments. There's a timeout argument, just like 
useEventLoop, defaulting to infinite timeout. So kfmclient can use a short 
timeout without affecting other apps hoping the reply will come this 
millenium.

>
> In general I think that adding asynchronous DCOP-calls would be a more
> usefull feature.

 Yes, for some more advanced usage, but for the single calls like the one in 
kfmclient just timing out is good enough.

On Thursday 30 of January 2003 06:09, Malte Starostik wrote:
[snip]
> 2 seconds is *way* too short. Example: KProtocolManager uses a blocking (no
> event loop to prevent the ugly side-effects) DCOP call to ask for the proxy
> for a given URL when PAC/WPAD is in use. The first time this will take a
> bit longer, until the proxy script is downloaded, which can be well over 2
> seconds.
> I agree a timeout can be usefile, but then please make it more in the
> magnitude of 2 minutes than 2 seconds. Granted that might be a bit long,
> but you get the idea, don't you? :-)

 Well, but you know, waiting for Konqy to fire up for 2 minutes is maybe way 
too long ;).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcopclient.cpp.patch
Type: text/x-diff
Size: 5067 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030130/49f2034c/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcopclient.h.patch
Type: text/x-diff
Size: 2409 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030130/49f2034c/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcopref.cpp.patch
Type: text/x-diff
Size: 1022 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030130/49f2034c/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcopref.h.patch
Type: text/x-diff
Size: 13009 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030130/49f2034c/attachment-0003.patch>