Re: GNU-Pth and GLIB

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Dan Maas wrote:
Hi Dan,

> I claim that the majority of glib users will not benefit from a threading
> API. First of all, Gtk-based GUI apps have NO business running in more than
> one thread - there are just too many ways to screw yourself up. (need to do
> stuff like async DNS lookups? fork another process. Network I/O? multiplexed
> non-blocking is the answer)... 

No, by calling gdk_threads_enter/leave it works perfectly. 

> Second, anyone planning to use glib in a
> high-performance server will know enough about what they're doing to make an
> appropriate choice of concurrency technique. Cooperatively-scheduled threads
> (and multithreading in general) are certainly useful *in some cases*, but
> those cases will rarely intersect the typical uses of glib/Gtk.

GLib just provides a very thin layer on top of the native thread library, so
if you're planning to write a high-performance server on top of the native
thread implementation (thats what many do, see ACE, OmniORB), you can use GLib
to make it portable, which is hard to get right otherwise (as you can see in
the amount of ifdefs and configure.in-checks in GLib). That said, I agree,
that some multithreaded programs could as well (or some even should) use a
main loop and an event driven system instead of multithreading.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi ira uka de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |