Re: Work woth GUI from a thread that was made by pthread_create function

[Soeren Sandmann <sandmann daimi au dk>]

[dropping gtk-devel-list - that list is for development *of* gtk+ and
 friends, not development *with* them]

Pavel Machek <pavel ucw cz> writes:

> > That's a bit strong to say use heavy processes, not threads.  The glib
> > and gdk functions do make it easy to attach handlers to i/o events,
> 
> Why? Process switch is not much slower than thread switch. Processes
> are more portable, easier to debug, .... 

..., don't limit stack size, don't impose locking thoughout all
libraries such as libc, glib, ...

The *only* advantage to threads over processes is that communication
between them is simpler because they live in the same address
space. This is also the reason they are difficult to debug.

I don't believe that process switches are significantly slower than
thread switches, but if it really is a bottleneck important enough
that it matters, you are doing something stupid, like creating a
thread/process per client or otherwise having the number of
threads/processes depend on the size of your data. If you do that,
context switches will kill you, no matter if you use threads or
processes.

In many cases where you think you want threads, you think so because
you want your user interface to stay responsive during lengthy
computations or i/o operations. That's definitely an admirable goal,
but there are better ways to do it than threads. Glib's mainloop has
all the primitives you need.