Nir Aides <n...@winpdb.org> added the comment: > It's a dual-core Linux x86-64 system. But, looking at the patch again, the > reason is obvious: > > #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate > >tick_counter % 1000 == 0)) > > `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, > which based its speculative operation on the number of elapsed opcodes (and > which also gave bad latency numbers on the regex workload).
The flag_check_depleted is there to work around this problem. It is raised by waiters which timeout. What distribution and version of GNU/Linux are you using? As for the CLOCK_THREAD_CPUTIME_ID clock, support was added to FreeBSD recently in version 7.1, which I guess is not good enough: http://www.freebsd.org/releases/7.1R/relnotes.html I did not find yet anything on Solaris. Do you know of an alternative way to measure thread running time on Posix? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7946> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
