[omniORB] Simple questions about orb->run(), orb->destroy() and omniINSPOA

[Duncan Grisby]

On Monday 22 October, Patrick Hubert wrote:

> 1- Do I really need to call orb->run()? Is CORBA::ORB_init() sufficient to
>    bootstrap all the necessary ORB elements?
> 
>    We already have a multithreaded environment, but I was hoping to avoid
>    creating a thread only to do the 'orb->run()' call.

In omniORB, you never have to call orb->run(). The CORBA specification
says that a portable application must call it, though, and other ORBs
are not so generous :-)

(For the pedantic, there is one situation in omniORB 4 where you do
have to call orb->run(). omniORB 4 supports the new MAIN_THREAD_MODEL
POA policy that means calls are dispatched on the main thread, not an
ORB-created thread. In that case, you have to call orb->run() from the
main thread.)

> 2- Is it really necessary to call orb->destroy()? Can we assume that upon
>    exit the OS will tidy up everything?

It is not necessary to call orb->destroy() -- your OS will clean up
for you.

omniORB 3 does allow you to deadlock against yourself if, for example,
you call destroy() inside an operation invocation. The proper
behaviour in these situations is for it to throw a BAD_INV_ORDER
exception; omniORB 4 does so.

> 3- If the omniINSPOA did not already exist, is it possible to create a POA
>    that would behave exactly like it (specifically for the human readable
>    object key generation for objects).

No, there is no standard way to do what the omniINSPOA does. That's
why it exists as a special thing. Most ORBs that support the
interoperable naming service have some sort of mechanism to do it, but
it's not standardised, and different ORBs do it in different ways.

>    I'd like to build and abstraction layer over our ORB related code so
>    that we could switch from different ORB implementations. Since we rely
>    a lot on the omniINSPOA, we have to make sure that we can have similar
>    functionality with other potential ORBs.

If possible, I'd recommend limiting the number of objects registered
in the omniINSPOA to a few as possible -- ideally just one used to
bootstrap everything.

Cheers,

Duncan.

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