Re: [gtk-list] Re: multithreaded apps

[Paul Barton-Davis <pbd op net>]

>Well, this isn't a BeOS advocacy list, but the manner in which the engineers
>did it is quite exceptional and Linux folks should hold judgement until
>they see it in action on slow 601 PPC chip. 
>
>The BeOS scheduler is quite fast and so is the file system.

I don't care how fast their scheduler is. I've done some research work
on OS scheduling, but even without that background, I can see no
justification (except an easier API) for creating more threads than are
really necessary. Context switches are evil, longer queues are
evil. They're worth trading in for some benefits, but I find working
with a single GUI thread that handles requests from other threads
sufficiently pleasant and speedy that this doesn't seem like a worthy trade.

BTW, given that BeOS wisely uses a server/client model for its UI,
ultimately it doesn't matter how many threads you have when it comes
to redrawing windows: everything shuttles through the server thread
that (currently) owns the hardware access.

>X Windows is *NOT* the entire GUI universe and that should be respected.

You specifically asked/suggested that this be done in a toolkit with
what to me seemed like a clear implication that it be an X
Window-based toolkit. I am well aware that there are other GUI's,
which is why I pointed out that you can't do what you suggested with
*X Windows*.

--p