Re: Thread-save posting of events



Hi James,

I really appreciated to read your experiences. Thanks for sharing them!

JAMES SCOTT wrote:
This response may be a little off topic.  But as I have followed this thread I understand your are moving 
some application to linux from MS.  Moreso, you are planning on using gtk to get that port done.  Here is a 
little of my experience with gtk threaded program design.

In fact I am currently evaluating the way I have to go when doing my
port. I currently see three options:
 - using the Free Pascal Compiler together with Lazarus (the original
program is written in Delphi)
 - using the g++ compiler together with QT
 - using the g++ compiler together with GLib/Gtk or GLibmm/Gtkmm

At the moment the last option seems to be the most attractive one. But I
will not make the decision alone, instead my task is to make a solid
proposal and show it to the rest of our developers.

   1. having gtk thread security features turned on is required if you
      plan to call gtk_ api's from more than one thread: Which you
      should NOT try to do.
[...]

Yes, indeed I plan to use only the main thread for GUI stuff. That fits
well with the program design I'm usually using.

   2. Spend some time devising a way to collect data values that need to
      be visually represented in gtk inside a container or memory
      structure that you can g_new0() allocate. 
         1. Then pass that pointer from the background thread to the
            foreground GTK main thread for display or updating
               1. maybe using GAsyncQueue to pass the pointers
[...]

   3. For gtk main thread to background thread interchanges look over
      the g_idle/g_timeout set of apis and potentially
      g_io_channel/watch apis; along with  g_mutex 'es where needed.
[...]

I think that this can be a good substitute for the
SendMessage/PostMessage functions I used.

   4. If you look at how gtk suggest you setup for multi-threaded
      program, it describes wrapping the call to gtk_main() with (
      gdk_threads_enter(); gtk_init();
      gtk_window...;gtk_main();gtk_threads_exit() ).  What is not so
      obvious is that this protects most callback except for
      g_timeout... g_thread... based functions;  as those callbacks
      occur inside the current gtk_main loop.
         1. You need to consider using gdk_threads_enter/exit in any
            g_timeout/g_thread/g_io_ based routine
         2. if you follow me thus far, then you will never call a
            gtk/gdk routine from outside the gtk_main loop or thread;
            except for maybe g_io_watch based functions.

I'm not sure if have understood this but as described above I will try
to follow 4.2 here :-)

   5. Socket based, and other OTHER PROCESS, communication wheter a pipe
      or a socket or orther mechanism may lend itself to g_io_channel
      and g_io_watch based apis.
[...]

Yes, most probably I will add private instances to some threads with
g_main_loop_new()/g_main_context_new().

   6. Finally, be careful how you implement or use classic unix
      signals:  Danger, Danger Will Robinson..

Is it possible to work with signals if they are only handled by the main
thread? Anyway I'm not sure if I will need signals at all...

I can not stress enough that you need to buy the book, readit, and
workout some off-project tests before pounding out a ported
application.  You will find gtk/glib to have a rich set of widgets and
programming constructs that make using it almost fun.

Of course I will start with some small concept evaluations before doing
the whole port. What do you mean with "the book"? Which book(s) would
you recommend for Gtk/GLib or even Gtkmm/GLibmm programming?

I hope some of what I've said help your quest.

Your comments helped me a lot. Thanks again!

/Tobias

-- 
NOA Audio Solutions Vertriebsges .m.b.H.   Tel: +43-1-5452700
Johannagasse 42/4                          Fax: +43-1-545270014
A - 1050 Wien                              Www: http://www.noa-audio.com







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]