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