Dan Mick added the comment:
Belaboring this a bit just in case what I learn helps with the interpreter
change:
seems like threading.Thread.start() is hanging in its normal wait for start
code:
(gdb) py-bt
#4 Frame 0x25d4de0, for file /usr/lib64/python2.7/threading.py, line 339, in
wait
Dan Mick added the comment:
So, finally got to a Fedora21 beta to try this out today; the immediate
problem, as identified by Joe Julian, is the shutdown() call in the __del__
method of Rados.
Presumably something about object destructors is clashing with starting new
threads; the hang
Antoine Pitrou added the comment:
Thanks for the explanation.
I confess I don't fully understand the change in 7741d0dd66ca, but it
does seem to have the side effect of not actually allowing exit while
there are outstanding daemon threads not hitting Python.
That's a bit weird, as that
Roundup Robot added the comment:
New changeset 4ceca79d1c63 by Antoine Pitrou in branch '2.7':
Issue #21963: backout issue #1856 patch (avoid crashes and lockups when
https://hg.python.org/cpython/rev/4ceca79d1c63
--
nosy: +python-dev
___
Python
Antoine Pitrou added the comment:
I've reverted the original changeset. I still believe it is likely to be an
issue on the ceph side, though, and the changes remain in 3.x.
--
resolution: - fixed
stage: needs patch - resolved
status: open - closed
type: - behavior
Changes by Joe Julian jjul...@io.com:
--
nosy: +Joe.Julian
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
___
Python-bugs-list mailing
Dan Mick added the comment:
Hi; I'm the original author of the code in the Ceph CLI.
The reason it does what it does is that the Python CLI calls into librados
(Ceph, through ctypes) to connect to the cluster; that connection can block for
various reasons, so it's spawned in a thread; after
Joe Julian added the comment:
I suspect the underlying problem is that the fix expects the daemon threads to
hit a point where they try to acquire the GIL and that's not going to happen
with these librados threads; they stay in librados.
--
___
STINNER Victor added the comment:
Oh by the way, I also prefer to revert the commit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
Antoine Pitrou added the comment:
I would favour reverting. The crashiness of daemon threads is not new, so
fixing it late in the 2.7 cycle wasn't really necessary IMO.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
As a sidenote, I wonder if the Ceph issue would also occur on 3.x. I guess we
won't know until Ceph is ported (is it?).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
Antoine Pitrou added the comment:
Note that this may very well be a bug in Ceph... Is any of the Ceph authors
nosied here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
STINNER Victor added the comment:
@Benjamin: What do you think? Should we revert the changeset 7741d0dd66ca in
Python 2.7?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
Benjamin Peterson added the comment:
Antoine is probably right that we should revert. I wonder what the exact
problem with Ceph is, though.
On Tue, Sep 30, 2014, at 18:55, STINNER Victor wrote:
STINNER Victor added the comment:
@Benjamin: What do you think? Should we revert the changeset
Charles-François Natali added the comment:
Agreed with Antoine and Benjamin.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
___
New submission from Ned Deily:
doko in msg222768 of Issue1856:
http://tracker.ceph.com/issues/8797 reports that the backport to 2.7 causes a
regression in ceph.
--
messages: 222795
nosy: benjamin.peterson, doko, ned.deily
priority: release blocker
severity: normal
stage: needs patch
Changes by Ned Deily n...@acm.org:
--
nosy: -ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21963
___
___
Python-bugs-list mailing list
STINNER Victor added the comment:
Does anyone have a *simple* script to reproduce the regression?
The changeset 7741d0dd66ca looks good to me, Python 3 does the same thing since
Python 3.2 (the new GIL).
Anyway, daemon threads are evil :-( Expecting them to exit cleanly
automatically is not
STINNER Victor added the comment:
The changeset 7741d0dd66ca looks good to me, Python 3 does the same thing
since Python 3.2 (the new GIL).
Oh, I forgot to say that the simplest way to fix the regression is to revert
this commit... As I wrote modifying the code to cleanup Python at exit is
19 matches
Mail list logo
