timeouts in DCOP calls

[Waldo Bastian]

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 :)

>  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.

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

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com