Hi all,
Yesterday I opened a thread for this issue where I was calling
sys.setcheckinterval() with sys.maxint and then try to set it to a
lower value but did not succeed with that. Here it is:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/fc01a6470245a704/f80733445ce30a36#f80733445ce30a36
I think we might have a bug or a undocumented intention.
Here is the related code in Python/ceval.c, line number 833 Python
2.6.2 source code:
if (--_Py_Ticker < 0) {
if (*next_instr == SETUP_FINALLY) {
/* Make the last opcode before
a try: finally: block uninterruptable. */
goto fast_next_opcode;
}
_Py_Ticker = _Py_CheckInterval;
tstate->tick_counter++;
>From what I understand is this, when you call sys.setcheckinterval()
with some value, _Py_Ticker volatile variable is not updated until
next context-switch. As in our example we set _Py_CheckInterval to
sys.maxint() then the thread starts ticking and even we set
checkinterval to a lower value, it is never updated as it waits for
the next context switch. Of course, if you do a blocking call, context
switch occurs and you think everything is fine, but as _Py_Ticker gets
never to "0" every thread starts running till finding a blocking call
which, in turn results in uncontrolled thread scheduling behavior.
As far as I understand, setcheckinterval() never designed to handle
such big values like sys.maxint to simulate unpreemtable behavior. If
the case is so, I think in any way we should document it somewhere.
Comments?
Thanks,
--
http://mail.python.org/mailman/listinfo/python-list
