Kirill Smelkov added the comment:
:) Yes and no. PyPy did not make a new release with the fix yet.
--
___
Python tracker
<https://bugs.python.org/issue38
Kirill Smelkov 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#msg35
Kirill Smelkov added the comment:
> > Maybe issue38106 related.
>
> That looks plausible, but unfortunately I'm still able to reproduce the hang
> with your PR (commit 9b135c02aa1edab4c99c915c43cd62d988f1f9c1, macOS 10.14.6).
Thanks for feedback. Then hereby bug is
Kirill Smelkov added the comment:
Ok, I did https://github.com/python/cpython/pull/16047.
--
___
Python tracker
<https://bugs.python.org/issue38106>
___
___
Change by Kirill Smelkov :
--
keywords: +patch
pull_requests: +15669
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16047
___
Python tracker
<https://bugs.python.org/issu
Kirill Smelkov added the comment:
I agree it seems like a design mistake. Not only it leads to suboptimal
implementations, but what is more important, it throws misuse risks onto the
user.
--
___
Python tracker
<https://bugs.python.org/issue38
Kirill Smelkov added the comment:
Maybe issue38106 related.
--
nosy: +navytux
___
Python tracker
<https://bugs.python.org/issue26360>
___
___
Python-bugs-list m
Kirill Smelkov added the comment:
Thanks for feedback.
--
___
Python tracker
<https://bugs.python.org/issue8410>
___
___
Python-bugs-list mailing list
Unsub
Kirill Smelkov added the comment:
And it is indeed better to always do pthread_cond_signal() from under mutex.
Many pthread libraries delay the signalling to associated mutex unlock, so
there should be no performance penalty here and the correctness is much more
easier to reason about
Kirill Smelkov added the comment:
Thanks for feedback. Yes, since for Python-level lock, PyThread_release_lock()
is called with GIL held:
https://github.com/python/cpython/blob/v2.7.16-129-g58d61efd4cd/Modules/threadmodule.c#L69-L82
the GIL effectively serves as the synchronization device
Kirill Smelkov added the comment:
At least condition variable signalling has to be moved to be done under mutex
for correctness: https://bugs.python.org/issue38106.
--
nosy: +navytux
___
Python tracker
<https://bugs.python.org/issue8
Kirill Smelkov added the comment:
I still believe there is a race here and it can lead to MEMORY CORRUPTION and
DEADLOCK: https://bugs.python.org/issue38106.
--
nosy: +navytux
___
Python tracker
<https://bugs.python.org/issue433
New submission from Kirill Smelkov :
Hello up there. I believe I've discovered a race in PyThread_release_lock on
Python2.7 that, on systems where POSIX semaphores are not available and Python
locks are implemented with mutexes and condition variables, can lead to MEMORY
CORRUPTION and DEA
13 matches
Mail list logo