how to start a new thread from a GUI

[Donn Cave]

Quoth Brian Kelley <bkelley at wi.mit.edu>:
| Donn Cave wrote:
[re performance issue with threads]

|> Lose 30%??!!  Where does it go, do you have any idea?

| Python has a global lock during threading so that only one python 
| instruction can be running at a time.  If you GUI runs a lot of python 
| calls and your threaded process runs a lot of python calls. 
|  Bingo---you're hosed.

So is this primarily about serialization of computations that could
be executing in parallel on multiple CPUs?  Or are you hitting the
lock so often that the cost of the lock itself is detracting noticeably
from overall throughput?  I know about the lock, but I'm still surprised.

| Fortunately running components in other processes is relatively easy. 
|  There are a lot of remote proxies running around out there.  The main 
| problem is asynchronous I/O because not only do you have to connect to 
| the operating systems I/O you have to work into the GUI systems I/O and 
| event loop.  Gtk/Tk/Qt and wxPython allow for fairly easy hooks into 
| their event loop so you can poll sockets/pipes with a simple callback or 
| timer mechanism(which of course is GUI specific).  Even COM and CORBA 
| have to deal with this reality.  If you care to dig deeper you can check 
| out the execellent fnorb (python corba orb) documentation for working 
| with GUI event loops.
|
| This kind of thing really gets hard for novices incredibly quickly, it 
| quite literally is a big old brick wall for a lot of people.  Hopefully 
| we'll be able to fix it one day :)

Oh yeah.  I will look at fnorb.  I have thought recently about
whether stackless Python could be used to emulate a normal
procedural model on top of an I/O event driven dispatcher,
using continuations to sequence the event responses.  No great
enlightenment yet, but I will write back if I get anything.

	Donn Cave, donn at drizzle.com