Christopher Subich <[EMAIL PROTECTED]> writes: > the primary benefit (on uniprocessor systems) that if one thread > executes a blocking task (like IO writes) another thread will receive > CPU attention.
On multiprocessor systems, of course, the benefit is that threads can run on separate CPUs. This could possibly be addressed by transparently running one OS thread for each CPU, each containing a set of light weight threads, and I hear people are thinking about that for Erlang (light weight processes language extravaganza). In the meanwhile, you can of course solve this by running two separate instances of your program that communicates with each other somehow. Another benefit is that you can have more threads than the limit the OS imposes on you, and they can also be made quite a bit less memory consuming. Some language implementations manages to deal with hundreds of thousands, and in some cases even millions, of threads this way. > They're not in the standard library because implementing microthreads > has thus far required a very large rewrite of the CPython architecture > -- see Stackless Python. Ruby's built-in threading also work something like this (if I understand Stackless Python correctly). (http://www.rubycentral.com/book/tut_threads.html) Personally, though, I think treating treating light weight threads as separate processes (which can only pass messages in between each other, but do not share scope in any way), like Erlang, seems to make dealing with massive concurrency easier. -- Björn Lindström <[EMAIL PROTECTED]> Student of computational linguistics, Uppsala University, Sweden -- http://mail.python.org/mailman/listinfo/python-list