Am Mittwoch, den 06.07.2005, 04:00 +0000 schrieb Dennis Lee Bieber:
> {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.
> """
>
> It will take someone who's actually worked on the runtime
> interpreter, or studied the code, to, uhm, "interpret" all the above
> tidbits...Not really, it's quite trivial. Anything that touches the Python/C API needs the GIL. [Python] <--Python/C API --> [Python module in C] <--some API--> [legacy C code] Now a well behaved Python C module does release the GIL before doing anything that might block/take a long time. The drawback in a Python with threading support that runs just one thread is the additional locking overhead. OTOH it's only done for operatations that will probably take a long time anyway. (And long is a relative term here *g*). Andreas
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- http://mail.python.org/mailman/listinfo/python-list
