decorators vs GIL

[G. S. Hayes]

Jarek Zgoda <jzgoda at gazeta.usun.pl> wrote in message news:<cf8n4s$b7u$3 at atlantis.news.tpi.pl>...

> 

> Try GUI programming without using threads.



For the GUI tasks that I've done (mostly data visualization stuff for
doing sophisticated views and edits on SQL databases and music
visualization software for doing realtime FFT/spectrum
analyzer/oscilloscope kinds of things that move with the music) it's
been absolutely no problem to use real processes for GUI work.  Why
exactly do you not want protected memory for these things?



Lots of big, sophisticated GUIs are implemented without threads (e.g.
Netscape Navigator/Communicator).  It almost always winds up being
easier on the programmer and more responsive for the user in the long
run.



Threads often seem simple at the outset, but most of the time they
wind up being far more complex to program and debug than judicious use
of state machines and processes.   The major exception is libraries
(especially matrix-math kinds of things) where the internals are so
deeply entwined that it's not easy to figure out well-segmented subset
to put in shared memory.  Often (but not always) the amount of work it
takes to figure out all the locking issues is a lot higher than what
it would've taken to seperate the data structures out cleanly.  And
sometimes you have legitimate real-world needs that require threads
(most often libraries designed around that model or the two MAJOR
platforms, Java and Windows, without good multiprocess support, but
sometimes problem domains where you really NEED all kinds of crazy
shared memory data structures and segmenting them out doesn't buy you
much).