[omniORB] Integration into a foreign event-loop

Duncan Grisby duncan at grisby.org
Wed Jul 22 19:23:42 BST 2009


On Wednesday 15 July, "Felix Nawothnig" wrote:

> 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).

Does it really?  I don't know anything much about Qt, but a quick search
around finds lots of information about multi-threaded programming with
Qt.

[...]
> So, this leaves me with two options:
> 
> a) Integrate Qt into the omniORB event-loop.
> 
> or
> 
> b) Integrate omniORB into the Qt event-loop.

omniORB doesn't have an event loop per se. It always has multiple
threads handling incoming calls and connection attempts. The main thread
POA policy is implemented using thread switching between the thread that
would normally have handled an upcall into the main thread. It is
therefore a lot less efficient than the normal threading policies.

> 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.

There's no current way you can do it.

Rather than the wait_for_work function you propose, I think a better
idea is to allow the application to register a function that is called
whenever a main thread task is inserted. i.e. at the point the code
currently does invoker_signal.signal(), it could call an
application-provided function. In your case, that function would send a
signal to the Qt main thread, instructing it to call perform_work.

If you send a clean patch that implements that scheme, I will definitely
consider integrating it in omniORB.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --



More information about the omniORB-list mailing list