[prev in list] [next in list] [prev in thread] [next in thread]
List: omniorb-list
Subject: Re: [omniORB] GUI and OmniORB Event loop
From: Anton Idukov <idukov () crtc ! spb ! ru>
Date: 2001-10-26 13:42:05
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic