[omniORB] omniORBpy deadlock.

[Luke Deller]

Hi Teemu,

My understanding is that you should not try to acquire
omni::internalLock while holding the python interpreter lock, because a
number of places in the omniORBpy code will acquire those locks in the
opposite order.

The omniORBpy code has a convenience class omniPy::InterpreterUnlocker 
which I believe is used for releasing the python lock before calling
code which might acquire the omni::internalLock (or which might block on
I/O).  You could look into using that or doing something similar in your
own code.

Regards,
Luke.

On Thu, 2005-09-22 at 17:45 +0200, Teemu Torma wrote:
> Python servant activation can lead to a deadlock in multi-threaded and 
> embedded python / omniORB application.
> 
> 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.
> 
> Any ideas?
> 
> Teemu
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list

**********************************************************************************************

Important Note
This email (including any attachments) contains information which is
confidential and may be subject to legal privilege.  If you are not
the intended recipient you must not use, distribute or copy this
email.  If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this
email are not necessarily the views of XPlan Technology.

It is the duty of the recipient to virus scan and otherwise test the
information provided before loading onto any computer system.
Xplan Technology does not warrant that the
information is free of a virus or any other defect or error.
**********************************************************************************************