This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author darkprokoba
Date 2006-02-17.09:52:00
SpamBayes Score
Marked as misclassified
Logged In: YES 

OK, let me try again :-)
The problem is in the global interpreter lock:
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.
Date User Action Args
2007-08-23 16:11:38adminlinkissue1432694 messages
2007-08-23 16:11:38admincreate