Kirill Smelkov <k...@nexedi.com> added the comment:
Victor, thanks for merging. > I'm surprised that we still find new bugs in this code which is supposed to > be battle tested! Maybe recent Darwin changed made the bug more likely. As discussed above (https://bugs.python.org/issue38106#msg351917, https://bugs.python.org/issue38106#msg351970), due to the GIL, the bug is not possible to trigger from pure-python code, and it can be hit only via using CAPI directly. I indeed started to observe the problem after moving locks and other code that implement channels in Pygolang from Python to C level (see "0.0.3" in https://pypi.org/project/pygolang/#pygolang-change-history) The bug was there since 1994 and, from my point of view, it was not discovered because locking functionality was not enough hammer-tested. The bug was also not possible to explain without taking lock lifetime into account, as, without create/destroy, just lock/unlock sequence was race free. https://bugs.python.org/issue433625 confirms that. I cannot say about whether recent macOS changes are relevant. My primary platform is Linux and I only recently started to use macOS under QEMU for testing. However from my brief study of https://github.com/apple/darwin-libpthread I believe the difference in scheduling related to pthread condition variable signalling under macOS and Linux is there already for a long time. > PyPy: it's now your turn to fix it ;-) PyPy people fixed the bug the same day it was reported: https://bitbucket.org/pypy/pypy/issues/3072 :) Kirill P.S. Mariusz, thanks also for your feedback. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38106> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
