[omniORB] Is this a bug in omniORB/omniORBpy

[Duncan Grisby]

On Wednesday 20 June, "Ivan Ivanov" wrote:

> The code below is from eg2_clt.cc.
> I have modified it so now it invokes omniORBpy
> to do some work. The bad news are that omniORB and
> omniORBpy instances fail to co-exist together.
> If I uncomment the orb.destroy() in python all
> following C++ code will fail. If I uncomment at least
> the orb->destroy() the program will hang apparently
> waiting for something to complete...

The root of the problem is that omniORB and omniORBpy share the same
ORB. That's why if you destroy the ORB in the Python code, the later
C++ code fails.

The hang when calling orb->destroy() from C++ is due to an unfortunate
consequence of the way Python works. After the call to
Py_Initialize(), the main thread holds the Python global interpreter
lock. It is still being held when you call orb->destroy(). omniORBpy
has hooked itself into the ORB, so orb->destroy() tries to clean up
some Python stuff (specifically, the thread state cache), which
involves locking the interpreter lock. This deadlocks.

The work-around for now is to release the interpreter lock around the
call to orb->destroy():

    hello(echoref, message);

    Py_BEGIN_ALLOW_THREADS
    orb->destroy();
    Py_END_ALLOW_THREADS

I'll try to think of a cunning way to avoid the problem, but I think
it might be impossible.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --