[EMAIL PROTECTED] wrote:
I googled as suggested, and the answer isn't crystal clear. My
impression is that the problem is that a python thread must acquire the
GIL in order to execute, and the strategy for deciding which thread
should get the GIL when multiple threads are waiting for it is not
based on priority. Is that correct?
That's basically correct. I don't actually know what
the strategy is, though I suspect it's either not
formally documented or explicitly not defined, though
for a given platform there may be some non-arbitrary
pattern...
Think of it this way: you have threads to which you have
given different priorities (somehow, using a platform-dependent
technique). The high priority thread runs first (for the
sake of this example only) in the interpreter, executes
a number of bytecode instructions equal to sys.getcheckinterval()
(miraculously without calling any extension modules or
blocking in any other way, again for the sake of this
example), and then has the GIL taken away from it by
the interpreter, thus blocking the thread. The interpreter
then gives the GIL to the lower priority thread (because
it isn't aware of the priorities assigned to the native
thread) and *it* runs for sys.getcheckinterval()
bytecode instructions, which might be a rather long
time. You have effectively no way to force the higher
priority thread to get the CPU whenever it is ready to
run, so long as the lower priority thread is also ready
to run. In effect, Python doesn't see the priorities at
all, and it is in almost sole control of which thread
runs when.
Or something like that. I'll rapidly be corrected if
I'm fundamentally wrong (and maybe even if I'm not ;-).
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
