Re: [gtk-list] Re: multithreaded apps

[Paul Barton-Davis <pbd op net>]

In message <199904170101.SAA08181@mag.ucsd.edu>you write:
>
>> A thread per window?  But that's insane -- it would create hundreds of 
>> threads per application in no time.  Or do you mean "a thread per
>> top-level window"?
>> 
>
>Yep, it's pretty insane and it's impressive as hell to to watch running
>under and OS with a soft realtime scheduler. 

      [ ... ]

>I'd personally like to see some of these features in some X based GUI
>kit, since this kind of stuff is unspeakably bitch'n.

You can't do this (yet) with X. Unless someone has done a better job
of it than has previously been reported, even the nominally
multithread X libraries don't do a good job of supporting
multithreaded applications. GTK+ or any toolkit could do whatever it
wanted to, but its not going to really get around this fundamental
limitation.

Also, its not as unspeakably bitchen as you allude. Although from a
programming point of view it makes things easy, it can cause a
substantially increased workload for the OS scheduler. If I wanted
"soft real time" performance, the last thing I would want to do is to
fork 200 threads (my current "soft real time" project typically has
about that many windows, sometimes more). The idea that the scheduler
has to trawl through and cause that many threads to run each time I do
something that exposes or otherwise causes a redraw of every window is
absurd.

The GTK+-with-IPC-via-gtk_input_add model that I alluded to creates
just one UI thread that can handle redraw requests from an arbitrary
number of windows/display objects, and doesn't burden the OS scheduler
anymore than necessary.

--p