From kde-core-devel  Thu Sep 30 17:05:07 2004
From: Waldo Bastian <bastian () kde ! org>
Date: Thu, 30 Sep 2004 17:05:07 +0000
To: kde-core-devel
Subject: Re: RFC: DBUS & KDE 4
Message-Id: <200409301905.11033.bastian () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109656397625022
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart5285542.5z2zTfmR40"

--nextPart5285542.5z2zTfmR40
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
remote calls. In particular, if you make an outgoing call and wait for an=20
answer, what do you do with arriving incoming calls? If you handle them you=
=20
may create unexpected reentrancy (compare it with the evils of=20
processEvents), if you don't handle them you may create deadlock, because=20
your outgoing call could have caused the incoming call and depend on its=20
completion.

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

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

[*] Disclaimer, the above is recalled from memory, actual DCOP behavior mig=
ht=20
be different.

Cheers,
Waldo
=2D-=20
bastian@kde.org  |  Wanted: Talented KDE developer  |  bastian@suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html

--nextPart5285542.5z2zTfmR40
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQBBXDzHN4pvrENfboIRAhTIAJik7Wo9cp8pO4i0OTftWwDznkPnAJ9RHoPN
qvfR8X6OX/EVM2+F2DqusA==
=m2H0
-----END PGP SIGNATURE-----

--nextPart5285542.5z2zTfmR40--