Python threads: backed by OS threads?
Donn Cave
donn at u.washington.edu
Thu May 11 14:44:45 EDT 2000
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
More information about the Python-list
mailing list