DCOP: Deadlock protection and reentrancy

[Koos Vriezen]

On Wed, Oct 06, 2004 at 08:05:57PM +0200, Waldo Bastian wrote:
> 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.

Would be a big win for plugin issues. (just an idea that pops-up, but
maybe a timeout time waiting in case apps turn out to be MT after all)

> > 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?

It was a hard to reproduce case (obvious). Problem was that after a
plugin is created, KHTML wanted it to resize to the layouted metrics. In
the meantime, the plugin was doing a javascript call (which it does
default nowadays). This lead to the collision like in the BR. Looks to
me hard to make a testcase, because the returning call must be done
before the first call arrives and get a chance to set the key value (if
I'm not mistaken, assumption made on your explaination, not the
sources).

Koos