On 2005-07-06, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On Tue, 05 Jul 2005 16:01:23 -0000, Grant Edwards <grante at visi.com>
> declaimed the following in comp.lang.python:
>
>> Or is the Python interpreter actually doing the context
>> switches itself?
>
> It would seem to be close to doing that, if it has that internal
> "quantum" of releasing the GIL every 100 bytecodes...
Right, but I think that's just _allowing_ a context switch
rather than performing one. The other interpreters are blocked
waiting for the GIL and releasing it lets one of them run.
Though the effect is pretty much the same, it's quite different
than having a single interpreter that does the scheduling and
context switching itself within a single OS process/thread.
> At the least, the GIL release/reacquire would be similar to
> having a C-language program doing sleep() to let other tasks
> run. I'll admit that I don't know if creating a Python thread
> also creates a new interpreter from scratch (after all,
> Windows doesn't have a fork() operation).
If I were doing it, I don't think I'd use fork() and create a
second address space. I'd use a "lightweight" thread. All of
the interpreter instances would share a single address space.
I know that Win32 has threads.
> It may be that the GIL toggle is part of a thread state
> save/restore operation, and could thereby be looked on as a
> high-level context switch with the OS-level context switch
> basically selecting from the threads blocked on the GIL.
Right -- I think that's what's hapenning. I really ought to go
look at the CPython source code instead of just sputing
conjecture.
> {I'm going to louse up the message tracking here by pasting part of your
> follow-up into one response}
>
> 2> Upon further thought, that just can't be the case. There has
> 2> to be multiple instances of the intepreter because the
> 2> interpreter can make C system calls that block (thus blocking
> 2> that instance of the interpreter). Other Python threads within
> 2> the program continue to run, so there must be multiple Python
> 2> intepreters.
>
> From the documentation:
>
> """
> The lock is also released and reacquired around potentially blocking I/O
> operations like reading or writing a file, so that other threads can run
> while the thread that requests the I/O is waiting for the I/O operation
> to complete.
> """
I know. I've worked on modules that release the GIL and call
blocking operations. My point is that when an interpreter
calls a blocking operation, the interpreter itself blocks. It
stops running. It goes to sleep. But, other Python threads
keep running, so there must be other interpreters running those
threads.
> Otherwise, I'd say convert the number cruncher to a compiled
> module that can be started as a Python thread, drop into the
> compiled code, give up the GIL, and crunch away -- only
> acquiring the GIL when it has results to give back.
Unfortunately that means you've got to debug a number cruncher
that's written in C.
--
Grant Edwards grante Yow! I'm shaving!! I'M
at SHAVING!!
visi.com