threads and sleep?

[Andreas Kostyrka]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.python.org/pipermail/python-list/attachments/20050713/545d7150/attachment.sig>