[omniORB] omniOrbPOA deadlock

[Renzo Tomaselli]

Duncan,
    I investigated further about this deadlock, since it hides some other
(application-dependent) hazards.
To anyone interested, I got my system working after applying the rule bel=
ow:

- if an etherealize method is likely to delete a servant because of a
_remove_ref, don't do it if this in turn might lead to another etherealiz=
e.
Just record the servant somewhere, then do _remove_ref after deactivation=
 is
completed, within the deactivation thread. This requires a cond. var. to
wait for completion; etherealize() just signals it.

This solves this deadlock and others derived from it. Somewhat tricky, bu=
t
it works.
Btw, this issue is much the same as the infamous deadlock occuring on NT
when joining a thread within the context of DLL startup/shutdown.
Thanks,

Renzo

-----Original Message-----
From: Duncan Grisby <dgrisby@uk.research.att.com>
To: Renzo Tomaselli <renzo.tomaselli@tecnotp.it>
Cc: Omniorb list <omniorb-list@uk.research.att.com>
Date: mercoled=EC 11 luglio 2001 12:37
Subject: Re: [omniORB] omniOrbPOA deadlock


>On Monday 9 July, "Renzo Tomaselli" wrote:
>
>>     there seems to be a deadlock in poa.cc which is due to the actual
usage
>> of servant_activator_lock.
>
>I'll look into this. It does sound like a problem.
>
>[...]
>> All of this seems due to the strange identity switch of objrefs when t=
he
>> connected servant is deactivated: they switch from local to remote, so
that
>> next invokation goes through the normal marshalling procedure of remot=
e
>> objects and it calls back, although objref and servant are colocated.
>> I feel this influences performance of servants managed by a servant
>> activator, and even worse by servant locators. Beside the actual deadl=
ock
>> off course.
>
>omniORB 4 supports fast colocated calls in all situations, so the
>performance will no longer be an issue. The deadlock is probably still
>a problem, though.
>
>Cheers,
>
>Duncan.
>
>--
> -- Duncan Grisby  \  Research Engineer  --
>  -- AT&T Laboratories Cambridge          --
>   -- http://www.uk.research.att.com/~dpg1 --
>