--nextPart1972683.I9AsDopq9j
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 06 October 2004 19:54, Koos Vriezen wrote:
> Waldo wrote:
> [..]
>
> > NOTE: If client A and client B would call each other simultaneously the=
re
> > is still a risk of deadlock because both calls would have unique keys a=
nd
> > both clients would decide to queue the incoming call until they receive
> > a response on their outgoing call.
>
> Not your question, but is this left as-is or will this be handled too?

I guess we could check it for the simple case of two clients, but I don't s=
ee=20
a good way how to handle it with more than two clients.

> Eg.=20
> BR69346 was victim of this. Might be unlikely for 'normal' services, but
> DCOP'ing with plugins, that use both DCOP (eg. nspluginviewer), makes sync
> call unusable. I.e. for non-threaded apps, how likely is it that if one
> calls app A and, waiting for a respond, it receives a call from A, it does
> _not_ deadlock?

I'm not sure I fully understand the situation of BR69346, (in particular=20
whether it is a situation that we are supposed to handle that just doesn't=
=20
work correctly, or whether it hits on the situation as described in the NOT=
E=20
above) any chance you can make a testcase for it?

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

--nextPart1972683.I9AsDopq9j
Content-Type: application/pgp-signature

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

iD8DBQBBZDQKN4pvrENfboIRAhCnAJ0e2Pjl2Yga4O26tVWGtcSjEpeekgCgm9Dn
F2ujJymv5akSag5v+MO1Fns=
=QJ4R
-----END PGP SIGNATURE-----

--nextPart1972683.I9AsDopq9j--