threads and sleep?

[Grant Edwards]

On 2005-07-06, Peter Hansen <peter at engcorp.com> 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!!