[omniORB] omniORBpy deadlock.

[Duncan Grisby]

On Thursday 22 September, Teemu Torma wrote:

> The problem is that POA activate_object first takes omni::internalLock, 
> and whilst holding it, calls python servant _add_ref(), which in turn 
> takes omnipyThreadCache::lock (i.e., python interpreter lock).
> 
> The reverse sequence is also true in emebdded C++ code (we are using 
> Boost.Python) where the C++ code does some CORBA object manipulation.  
> Avoiding the python interpreter lock is slightly complicated and error 
> prone in this situation, especially if one is using _var's to hold 
> objects to make code exception safe.
> 
> The problem goes away by changing activate_object to call _add_ref() 
> after omni::internalLock has been released.

There are plenty of places where omniORBpy has to call into Python while
holding omni::internalLock, not just activate_object. I'm afraid that
the Python interpreter lock has to come after internalLock in the
partial lock order, so you have to release the Python interpreter lock
before calling into any omniORB code.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --