[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DCOP: Deadlock protection and reentrancy
From:       Waldo Bastian <bastian () kde ! org>
Date:       2004-10-06 18:05:57
Message-ID: 200410062006.02457.bastian () kde ! org
[Download RAW message or body]


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@kde.org  |  Wanted: Talented KDE developer  |  bastian@suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]