[omniORB] omniORB/omniORBpy in same address space - any benefit?

[Ivan Ivanov]

Thanks for the invaluable support, Duncan! 
This is *great* news for omniORBpy users!
Would Python 2.2b work with omniORB4 and omniORB2. If it's not tested
which one is?

regards,
Ivan Ivanov


-----Original Message-----
From: owner-omniorb-list@uk.research.att.com
[mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of Duncan
Grisby
Sent: Monday, November 12, 2001 3:50 AM
To: Ivan Ivanov
Cc: OmniORB
Subject: Re: [omniORB] omniORB/omniORBpy in same address space - any
benefit? 


On Tuesday 13 November, "Ivan Ivanov" wrote:

> omniORB and omniORBpy can be linked together in one 
> executable and live in the same process. They use the same 
> ORB instance however and one should not call orb.destroy()
> from python code for example. Duncan Grisby gave the idea 
> how to do the same in c++:

Actually, it _is_ safe to call orb.destroy() from Python. It isn't
safe to do it from C++, without the Py_BEGIN_ALLOW_THREADS thing.

> Now my issue is a quite general this time - is there 
> any performance benefit from binding together omniORB and 
> omniORBpy in the same address space. 
> The omniORBpy stubs/skeletons call invoke() in _omnipy - 
> they don't make use of local calls yet. It's even hard for me 
> to imagine how would they do so anyway.

With omniORB 3.0.x / omniORBpy 1.x, there may be a small performance
improvement to sharing an address space. The communication goes via
the TCP loopback, but looping back to the same process may be faster
than going cross process on some operating systems.

In omniORB 4.0.x / omniORBpy 2.x, there is a big performance
improvement, at least an order of magnitude. Calls between Python and
C++ (and vice-versa) use an in-memory transport, so they are much much
faster.

Cheers,

Duncan.

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