Armin Rigo <[email protected]> added the comment: Note that PyPy's method is almost like CPython, but with an additional twist: the thread that releases the GIL is not allowed to be the first one to acquire it again, if another thread is waiting.
We should think about this in the context of the JIT. Right now every compiled loop decrements the "bytecode counter" by some amount computed a bit randomly from the length of the loop. We could instead use the fast instruction to get the CPU timer. Note that there are additional CPU-dependent issues, like the fact that the CPU timers of multiple cores are out-of-sync; moreover it's unclear if other CPUs than x86 have a required super-efficient timer. These are all reasons for why the current solution works "well enough", and why it's a bit delicate to change it without a global RPython change (that would also affect other interpreters than PyPy-for-3.2). ---------- nosy: +arigo -pjenvey status: unread -> chatting ________________________________________ PyPy bug tracker <[email protected]> <https://bugs.pypy.org/issue1470> ________________________________________ _______________________________________________ pypy-issue mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-issue
