Re: threads and sleep?

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}
>=20
> 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.
>=20
> From the documentation:=20
>=20
> """
> 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.=20
> """
>=20
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBC1M8QHJdudm4KnO0RAttXAJ9lwBoK1Qt0UNlnR6BKRGPQzUGLLwCgobXq
1roene7WUotvUa1YQPQLGQs=
=0dz8
-----END PGP SIGNATURE-----

[plaintext signature.asc.1121242896.1663250294]
Received on Thu Sep 29 16:55:25 2005