Tiago Cogumbreiro wrote:
I agree with the title being misleading. But if you think about it an
article explaining GCondition, GMutex and g_thread_join() would also be
misleading, the correct title for that kind of article would be
"Threaded Programming with GThread" or "Threaded Programming with GLib".
Maybe the title should be "Interfacing Gtk+ with Threaded Programming",
what does the list think?
While it is sometimes unclear what gtk is;
is it a package distributed with pango, glib etc.
or is it a package which includes glib, atk, pango etc.
the truth is that it is both. Maybe "GTK+" is a package which provides
the "gtk" package, but then we're really just splitting hairs.
Actualy; I think "Threaded Programming with GThread" or
"Threaded Programming with GTK+" is splitting hairs because essentialy
they are the same thing. GTK+ applications are glib based, they use
GThread to interface with threads in a portable fashion.
There are a few more issues that i would like to cover in this article.
I would like to explain some of the details already explained in this
list, such as main loop related calls are thread safe, why users should
not use gdk_thread_enter/leave.
I'm sure you can find alot of argumentation for this in the mailing lists,
I think historicly, people prefered useing one dedicated GUI thread
because they were doing just that before gdk_threads_enter/leave came into
play, applications are easier to manage with one gui thread and I think
they perform smoother as well (since gtk+ doesn't have to fight for the lock).
Cheers,
-Tristan
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
