timeouts in DCOP calls

[Malte Starostik]

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

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

-Malte