Re: Thread-save posting of events
- From: Tobias Rapp <t rapp noa-audio com>
- To: JAMES SCOTT <skoona verizon net>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Thread-save posting of events
- Date: Tue, 03 Apr 2007 13:53:35 +0200
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]