RFC: DBUS & KDE 4

[Waldo Bastian]

On Thursday 30 September 2004 18:36, Aaron Seigo wrote:
> the question has be posed, but not answered: can the "stuff that is worse"
> be fixed and how much effort would that take? i know earlier you spoke
> about deadlock issues, can you point to where these problems exist
> exactly[1]?

I can give it a go I think. It has to do with how reentrancy is handled in 
remote calls. In particular, if you make an outgoing call and wait for an 
answer, what do you do with arriving incoming calls? If you handle them you 
may create unexpected reentrancy (compare it with the evils of 
processEvents), if you don't handle them you may create deadlock, because 
your outgoing call could have caused the incoming call and depend on its 
completion.

In DCOP this problem is worsened because of the lower level call/reply 
sequence (dictated by libICE?) I always get headache when I try to figure out 
how it works, but the idea is that the reply is coupled to the call by means 
of sequence, so you must handle calls in sequence otherwise the reply to one 
call is considered the reply to another call. We have put stuff on top of it 
(DCOPWait) to work around that limitation. DCOPWait is basically a reply that 
says, ok here is the mandatory reply, the actual reply with an actual call 
result will come later, it will be identified by this number.

Anyway, what DCOP does to handle the reentrancy/deadlock problem is to tag 
every call sequence with a number. So assume for example that A calls B and B 
calls C, and then C responds to B and then B responds to A, both calls will 
have the same number because they are part of a single sequence. This becomes 
usuful when A calls B, B calls C and then C calls A. A can now look at the 
sequence number and knows that it will deadlock if it doesn't handle the 
incoming call from C. So in that case A will process the call directly, but 
in other cases A will defer execution till it has got a response from B to 
reduce unneeded reentrencancy.

[*] Disclaimer, the above is recalled from memory, actual DCOP behavior might 
be different.

Cheers,
Waldo
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040930/99ada144/attachment.sig>