[omniORB] Integration into a foreign event-loop

Felix Nawothnig fn at drdannenberg.de
Thu Jul 16 00:46:53 BST 2009


Hello.

I'm writing a Qt application which implements a dozen of CORBA interfaces,
most of which are simple observer-like interfaces which cause some kind of
GUI update.

Now, as most widget toolkits Qt needs all GUI related calls be done in a
single thread (actually Qt even needs that thread to be the original
main() thread).

Up until now I just kept adding boilerplate code for each CORBA method
which marshals the data into the GUI thread (using Qt signals). Now the
amount of boilerplate code is getting out of hand - and I decided to try
do this properly instead.

I know I can get myself a single-threaded POA and use ORB::work_pending()
and ORB::perform_work(), possibly triggered by a Qt idle timer or
something that - but as I said, I want to do this _properly_ (not doing it
that way has practical reasons too - there is quite some real-time data
coming in via oneway methods and the application will run on a
battery-powered device, so I really don't want to spent lots of cycles
doing busy waiting).

So, this leaves me with two options:

a) Integrate Qt into the omniORB event-loop.

or

b) Integrate omniORB into the Qt event-loop.

The former is not really an option, as the result would be highly
unportable (I'd have to hook the system-dependent message queue) and would
require me to dig deep into Qt code I really don't want to dig into
(although the omniORB-side integration would be simple).

The latter would be rather simple - if there was an
ORB::wait_for_pending_work() method I could call from a non-main thread;
I'd just do that, when it returns I emit a signal to the GUI thread, it
will get dispatched and inside the handler I'd call ORB::perform_work().

Unfortunatly there is no such thing as ORB::wait_for_work().

And as far as I can say there is currently no way to achieve what I'm
trying to do with omniORB - correct me if I'm wrong.

Now, I've looked into corbaOrb.cc and I suppose It'd be easy for me to
hack  (I just need to make invoker_signal accessible for me, right?) - but
as there might be a chance for this functionality to end up in the
upstream distribution (I believe my feature request to be reasonable) I
thought I'd first ask for opinions regarding that matter here.

So, what do you think of an omniORB::wait_for_work()?

Cheers,

Felix





More information about the omniORB-list mailing list