[Bug 122020] doesn't start kdesvnd fast enough

[Modestas Vainius]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=122020         




------- Additional Comments From geromanas mailas com  2006-10-26 10:25 -------
Below I attach bug122020.tar.gz, a small testcase, demonstrating this bug. When you run it, you will get something like this on the console.

DCOPsrv: Starting DCOPsrv, registering as dcopsrv1
DCOPsrv: Starting new DCOPsrv service...
DCOPsrv: Starting DCOPsrv, registering as dcopsrv2
DCOPsrv: Starting new DCOPsrv service...
Executing the 1st DCOP call: service dcopsrv1 function sleep(3000)
DCOPcl: 1st dcop call sleep(3000) with timeout failed. The first part of the bug
Executing the 2nd DCOP call: service dcopsrv2 function sleep(4000)
2nd dcop call sleep(4000) w/o timeout returned 3000
2nd dcop call returned the return value (3000) of the 1st DCOP call. Bug proven!
Very strange! got a DCOPReply opcode, but we were not waiting for a reply!

sleep(int msecs) is a small DCOP function, which causes the process (the DCOP service provider) to sleep for msecs miliseconds and returns msecs value to the caller. As you a return value of the 2nd DCOP call is wrong (should have been 4000) due to this bug. And "Very strange! got a DCOPReply opcode, but we were not waiting for a reply!" message is where the real reply of the 2nd call (return value 4000) gets discarded.

I also attach a patch to avoid using timeout in kdelibs/kio/kio/kmimetype.diff It's not truly a fix for the actual DCOP bug, but rather a workaround to avoid it. The other workaround could be to establish a new DCOP connection and call with timeout on it, but, in my opinion, abandoning timeout is a clean and logical solution.

A true solution would be to fix this race condition in DCOP code. That's where experienced DCOP dev should step in. Or at least please clearly DOCUMENT this bug in DCOPClient documentation (e.g. a big fat warning that it is not safe to do another dcop call on the same connection if a previous call might have timed out).