[omniORB] GUI and OmniORB Event loop

[Anton Idukov]

Hi,
Plus for this. Today GUI programming is the work with many kinds of GUI 
Toolkits
(such as Gtk , Qt, Tk or Motif ). Such toolkits have custom event loop 
blocking
functions/methods usually placed inside main thread.
Plus XWindows API hasn't standard supported way
for asynchronios rendering.
I think work_pending()/perform_work() is not good method, and special 
for monitoring applications.
I think Better way is multithreaded orb with data channel ( for example 
c++ stl std::queue or std::list )
used by  CORBA end and  Timer or Idle work toolkit functions on other end.
In win32 GDI we need critical_section wrapper for Graphic Context use.
In many cases using work_pending() / perform_work() give us 
block'n'drugs apps :(

   
bjorn rohde jensen wrote:

>Hi,
>
> I did play a bit with CORBA GUI applications using X strictly for fun,
>and
>i would say, that usually you have two basic choices. ORB's have a
>blocking
>run() method, and a pair of work_pending()/perform_work() methods, and
>in
>my limited experience so do most GUIs such as X. You could write a
>combined
>event loop using the work_pending/perform_work methods of the orb and
>their
>GUI counter parts, or you can dedicate a thread to the event loop of the
>ORB
>and one to the event loop of the GUI. I chose to use threads, since i
>did
>not want to mess with the event loops, and the OS is probably quite a
>bit
>better at sharing the cpu resources between two event loops, than any
>mixed
>event loop, i was ready to write.
>
>Sincerely
>
>Bjorn Rohde Jensen
>
>
>
    Sincerely

    Anton