On 2005-07-05, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > Don't think you can do that with Python... The Python runtime > interpreter itself is running on a single processor.
I don't see how that can be. Under Linux at least, the Python threading module uses "real" OS threads, so there are multiple instances of the interpreter, right? Generally all but one of them will be blocked on the GIL, but there are still multiple interpreter threads (which can be on multiple different CPUs). Or is the Python interpreter actually doing the context switches itself? > The second thing is the infamous "global interpreter lock" > (pull up the Python documentation and do a search for that > phrase). The GIL is the issue. > Basically, even if the threads could be assigned to > processors, Can somebody explani why they can't? > this lock means only one thread can be performing Python > operations at a time -- a C-language number crunching module > /could/ release the lock, then do its number crunching in > parallel, reacquiring the lock when it finishes so it can > return its result(s) as Python objects. True. Python can execute C code in parallel, but not Python code. > Tou might get the results you want by not using threads, > instead spawning off completely new Python invocations > assigned to other processors. That should work, but managing the inter-process communication and syncronization is a pain. -- Grant Edwards grante Yow! If Robert Di Niro at assassinates Walter Slezak, visi.com will Jodie Foster marry Bonzo?? -- http://mail.python.org/mailman/listinfo/python-list