Author navytux
Recipients arigo, beazley, benjamin.peterson, brian.curtin, dabeaz, flox, jyasskin, kristjan.jonsson, loewis, navytux, ned.deily, paul.moore, pitrou, python-dev, r.david.murray, rhettinger, ronaldoussoren, sbt, scoder, shihao, techtonik, terry.reedy, tim.golden, tim.peters, torsten, vstinner, ysj.ray
Date 2019-09-11.16:39:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thanks for feedback. Yes, since for Python-level lock, PyThread_release_lock() is called with GIL held:

the GIL effectively serves as the synchronization device in between T2
releasing the lock, and T1 proceeding after second sema.acquire() when it gets to
execute python-level code with `del sema`.


a) there is no sign that this aspect - that release must be called under GIL -
   is being explicitly relied upon by PyThread_release_lock() code, and

b) e.g. _testcapimodule.c already has a test which calls
   PyThread_release_lock() with GIL released:

Thus, I believe, there is a bug in PyThread_release_lock() and we were just
lucky not to hit it due to GIL and Python-level usage.

For the reference, I indeed started to observe the problem when I moved locks
and other code that implement channels in Pygolang from Python to C level:
Date User Action Args
2019-09-11 16:39:46navytuxsetrecipients: + navytux, tim.peters, loewis, arigo, rhettinger, terry.reedy, beazley, paul.moore, shihao, ronaldoussoren, pitrou, scoder, kristjan.jonsson, vstinner, techtonik, jyasskin, tim.golden, benjamin.peterson, ned.deily, r.david.murray, brian.curtin, flox, dabeaz, torsten, ysj.ray, python-dev, sbt
2019-09-11 16:39:46navytuxsetmessageid: <>
2019-09-11 16:39:46navytuxlinkissue38106 messages
2019-09-11 16:39:46navytuxcreate