Python threads: backed by OS threads?

[Donn Cave]

Quoth Chuck Esterbrook <echuck at mindspring.com>:
| Richard Brodie wrote:
|> "Courageous" <jkraska1 at san.rr.com> wrote in message news:391A92A4.F64FF43A at san.rr.com...
|> > I see. Well, then all things considered, I have no idea why one
|> > would want to use python/OS threads at all. The uthread implementation
|> > on stackless really rips.
|> 
|> It depends on your reason for using threads. Sometimes, it just means
|> that you can write cleaner code. Having a multiprocessor, and using
|> multiple threads, and caring about the execution time of the Python
|> interpreter are putting you in something of a minority.
|> 
|> For one thing, it means that you are using an interpreted language
|> for something performance critical. In a lot of problems, the inner
|> loop is likely to end up in external modules which will multiprocess
|> fine anyway. If yours isn't one of them them sure, go ahead.
|
|
| The application server in Webware for Python is a good example where:
|
| * You want a great language like Python to develop your website (even if Python is slow).
| * There doesn't seem to be a magic inner loop that provides huge optimization pay offs
| * Multiple threads are a natural, because it's a server for multiple requests
| * Performance is important and multiple CPUs can/should help

You'd want to add to this analysis to assert that

 - multiple processes isn't an equally good answer.  A process is a thread
   minus a lot of headaches including the interpreter lock.

 - the interpreter lock really prevents full multi-CPU load.  Like the
   man said, a lot of action happens in external calls that unlock the
   interpreter for another thread.

	Donn Cave, donn at u.washington.edu