[omniORB] Use of OmniORB in an IDLE loop

[Duncan Grisby]

On Thursday 17 August, Laurent Pointal wrote:

> >From my reading of "Advanced CORBA Programming with C++", it is possible to
> have a new POA with monothread policy. Is it possible to have the ORB
> processing done in a function call like omni_process_requests(), which will
> be called in the context of an IDLE event of a GUI loop (in OmniORB3).

omniORB is always multi-threaded -- it is not at all feasible to
modify it so that it can be called from a single-threaded event loop.
It is possible to create a POA with the SINGLE_THREAD_MODEL policy,
but all that guarantees is that requests to objects in that POA will
be serialised -- it does not guarantee that they are always called by
the same thread. It also does not prevent a single ORB thread
interacting with the Igor system at an inopportune moment.

The approach with a queue of Action objects which you outline is a
sensible way to interface a single-threaded system with omniORB.
However, depending on what the event loop you are interfacing with
does, it may be possible to do things in a simpler way:

Declare a mutex which the main thread locks before entering the event
loop. When you receive an idle event, unlock the mutex, sleep for a
short while, then lock it again. In the bodies of the CORBA
operations, lock the mutex before interacting with the Igor system,
and unlock it afterwards. That way, you guarantee that only one thread
is running inside the Igor code at any time, but it is not always the
same thread. With any luck, the system won't notice, and everything
will work fine.

Hope that helps,

Duncan.

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