Re: Work woth GUI from a thread that was made by pthread_create function
- From: Sander Vesik <sv117949 ireland sun com>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: Pavel Machek <pavel ucw cz>, Michael Torrie <torriem cs byu edu>, gtk-app-devel-list gnome org, gnome-devel <gnome-devel-list gnome org>
- Subject: Re: Work woth GUI from a thread that was made by pthread_create function
- Date: Thu, 14 Feb 2002 13:06:14 +0000 (GMT)
On 14 Feb 2002, Soeren Sandmann wrote:
>
> [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.
>
You can do communication between processes using shared mmaps. A mmap
is in the same address space just like with using threads.
> 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.
>
I think the main reason for using threads at this point of time is that
you have all the necdcessary "middleware" but would need to invent it
otherwise.
Sander
I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]