Changes by Nikita Kovaliov nik...@maizy.ru:
--
nosy: +maizy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list mailing
Roumen Petrov added the comment:
STINNER Victor wrote:
[SNIP]I attach hang2.py which doesn't force the Python implementation
of RLock.[SNIP]
Ok. Fine with me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
Antoine Pitrou added the comment:
This bug has existed for ages. People who want sane behaviour should just
switch to Python 3. Closing.
--
resolution: - rejected
stage: needs patch - resolved
status: open - closed
___
Python tracker
STINNER Victor added the comment:
The attached test script demonstrates the issue on Python 2.6 and 3.2, and
code inspection suggests this is still valid for 2.7 and 3.4.
I disagree that Python 3.4 is affected: RLock has been reimplemented in C in
Python 3.2. Only the Python implementation
Roumen Petrov added the comment:
hmm issue still exist in master branch.
Lets wait python 4 for sane behaviour.
--
nosy: +rpetrov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
STINNER Victor added the comment:
hmm issue still exist in master branch.
For the third time, only the Python implementation has the bug, and it's not
used by default. So the bug was fixed in Python 3 since 3.2. It's time to
upgrade guys ;-)
--
Roumen Petrov added the comment:
STINNER Victor wrote:
For the third time, only the Python implementation has the bug, and
it's not used by default. So the bug was fixed in Python 3 since 3.2.
It's time to upgrade guys ;-)
Did you mean to downgrade? Tested with Python 3.5.0a1+ (default, Feb
STINNER Victor added the comment:
Did you mean to downgrade? Tested with Python 3.5.0a1+ (default, Feb 28
2015, 09:49:09)
Please make some effort to try to understand the issue.
I attach hang2.py which doesn't force the Python implementation of RLock. You
might try hang2.py on Python 2 and
STINNER Victor added the comment:
FYI I proposed a fix for eventlet to fix eventlet with Python 3 when
monkey-patching is used:
https://github.com/eventlet/eventlet/pull/187
The change forces the Python implementation of RLock, which is compatible with
eventlet monkey-patching. The Python
Lothsahn added the comment:
I am using Python 2.6.5 (we will be upgrading to Python 2.7.9 soon) and I
recently ran into this bug.
If I do any locking in a signal handler with RLocks, the entire system can
deadlock. I'm using this to serialize my IO so we don't have mismatched lines
in our
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list
Mike Meyer m...@mired.org added the comment:
I just ran into this issue in the logging module using 2.7. Here's the TB in
case it sheds any light on the issue
Traceback (most recent call last):
File ./crawler.py, line 531, in module
main(argv[1:]1:)
File ./crawler.py, line 522, in main
Charles-François Natali neolo...@free.fr added the comment:
Hmm, but that would break single-threaded programs which expect their
select() (or other) to return EINTR when a signal is received (which is
a perfectly valid expectation in that case).
Yes, that's why I said thats another story
Antoine Pitrou pit...@free.fr added the comment:
The first and most simple thing we could do would be to nuke the
Python version (and also the loggin hack at the same time): does that
sound reasonable ?
To me, yes, but I think it's better to ask on python-dev as for nuking
the Python
Antoine Pitrou pit...@free.fr added the comment:
That sounds like a good solution in the middle-term. Are there any
drawbacks? (apart from launching a thread)
Just to be clear: the approach I was suggesting is to have a resident
thread dedicated to signal management, not to spawn a new
Antoine Pitrou pit...@free.fr added the comment:
Yes, using synchronization primitives or doing I/O in Python signal handlers
isn't a good idea. Perhaps the signal docs should be clearer about that.
Of course, this wasn't ever safe code, and we're changing it (to have the
signal handler
Charles-François Natali neolo...@free.fr added the comment:
The core of the problem is that we don't just want those methods to be atomic
or thread-safe, but reentrant (or rather async-safe).
As such, protecting by a lock isn't enough (and it's not really feasible in
Python).
Note that the
Antoine Pitrou pit...@free.fr added the comment:
Note that another solution would be to use a dedicated thread for
signal management (like Java does), but that's another story.
That sounds like a good solution in the middle-term. Are there any
drawbacks? (apart from launching a thread)
Charles-François Natali neolo...@free.fr added the comment:
That sounds like a good solution in the middle-term. Are there any
drawbacks? (apart from launching a thread)
Just to be clear: the approach I was suggesting is to have a resident
thread dedicated to signal management, not to spawn a
STINNER Victor victor.stin...@haypocalc.com added the comment:
This affects the python implementation of RLock only.
In the issue #13550, it was discussed to remove completly the logging machinery
from the threading module. If we remove it, we don't need the Python
implementation of RLock.
Robert Collins robe...@robertcollins.net added the comment:
Normally I advocate very strongly for Python implementation of C accelerated
modules, but when the two implementations are not equivalent, having a simpler
Python one around does not help anyone (not users, other language implementors
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list mailing
New submission from Robert Collins robe...@robertcollins.net:
This affects the python implementation of RLock only.
If a signal occurs during RLock.acquire() or release() and then operates on the
same lock to acquire() or release() it, process hangs or assertions can be
triggered.
The
Jesús Cea Avión j...@jcea.es added the comment:
Adding myself to the nosy list because I am interested in the issue, but I
can't take care of this myself for a few weeks, at least.
Robert, would you consider to try to write a patch?
--
nosy: +jcea
versions: +Python 3.3 -Python 3.4
Changes by Antoine Pitrou pit...@free.fr:
--
stage: - needs patch
type: - behavior
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list mailing
Robert Collins robe...@robertcollins.net added the comment:
I'm not sure it is sensibly implementable in pure python: the semantics of
signal handling (AIUI) are that the vm is interrupted, sets a flag to say 'when
the GIL is released or the next bytecode interpretation happens, please process
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list
28 matches
Mail list logo
