On 2005-07-06, Peter Hansen <[EMAIL PROTECTED]> wrote:
>>>Or is the Python interpreter actually doing the context
>>>switches itself?
>>
>> Upon further thought, that just can't be the case. There has
>> to be multiple instances of the intepreter because the
>> interpreter can make C system calls that block (thus blocking
>> that instance of the interpreter). Other Python threads within
>> the program continue to run, so there must be multiple Python
>> intepreters.
>
> Maybe you should consider and explain what you mean by
> "multiple interpreters"?
That in a multi-theraded Python program, the code that
impliments the Python VM is executing "simultaneously" in
multiple contexts: one for each thread (and possibly one master
thread).
I was responding to somebody who said that there were two issue
with using multiple CPUs:
1) the interpreter (singular) only ran on one CPU.
2) the GIL.
My point was that 1) couldn't be true. There must be multiple
instances of the interpreter since in a multi-threaded Python
program, the interpeter blocks when making libc calls like
read() write() recv() send(), and yet other Python threads
continue to run. If there _were_ only a single interpeter, and
it ran only on a single CPU, then the GIL wouldn't be needed.
> As I understand the concept, and based on my several years'
> old reading of the virtual machine code, I wouldn't say there
> are multiple interpreters.
>
> There's a reason the GIL is the *global* interpreter lock...
Exactly.
--
Grant Edwards grante Yow! I've been WRITING
at to SOPHIA LOREN every 45
visi.com MINUTES since JANUARY 1ST!!
--
http://mail.python.org/mailman/listinfo/python-list
