DCOP: Deadlock protection and reentrancy

[Waldo Bastian]

On Wednesday 06 October 2004 19:54, Koos Vriezen wrote:
> Waldo wrote:
> [..]
>
> > NOTE: If client A and client B would call each other simultaneously there
> > is still a risk of deadlock because both calls would have unique keys and
> > 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 see 
a good way how to handle it with more than two clients.

> Eg. 
> 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 
whether it is a situation that we are supposed to handle that just doesn't 
work correctly, or whether it hits on the situation as described in the NOTE 
above) any chance you can make a testcase for it?

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/20041006/6c82bd6d/attachment.sig>