Thijs Triemstra li...@collab.nl added the comment:
Looks like this influenced mod_wsgi as well:
http://groups.google.com/group/modwsgi/browse_thread/thread/ba82b2643564d2dd
--
nosy: +thijs
___
Python tracker rep...@bugs.python.org
Changes by Brett Cannon br...@python.org:
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
___
Python-bugs-list
sorin sorin.sbar...@gmail.com added the comment:
Any idea if there is a nightly build for Python 2.6? The latest release was
2.6.4 and was 2 days before submitting the patch.
Or the only alternative is to build it myself? Any ideas on when we could see
2.6.5? - I tried to look for a release
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I have seen somewhere (ask google), that python 2.6.5 would be released
mid-march.
But except for a few platforms, python.org does not provide compiled binaries.
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Backported to 2.6 in r75749.
--
resolution: accepted - fixed
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
Antoine Pitrou pit...@free.fr added the comment:
The patch looks good to me.
And since Py_Finalize() claims to destroy all sub-interpreters and
free all memory allocated by the Python interpreter, I guess your
approach makes sense. Can you commit?
--
resolution: - accepted
stage: patch
Adam Olsen rha...@gmail.com added the comment:
Nope, no access.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Ok, I'll do it then!
--
assignee: - pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
Antoine Pitrou pit...@free.fr added the comment:
Patch was committed in trunk, py3k and 3.1. Waiting for 2.6 to be
unfrozen before I commit it there too.
--
stage: commit review - committed/rejected
status: open - pending
versions: -Python 2.7, Python 3.1, Python 3.2
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +pitrou
stage: - patch review
type: - behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
Changes by Aren Olson reacoc...@gmail.com:
--
nosy: +reacocard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
___
Python-bugs-list
Changes by Qiangning Hong hon...@gmail.com:
--
nosy: +hongqn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
___
Python-bugs-list
Adam Olsen [EMAIL PROTECTED] added the comment:
This bug was introduced by r53249, which was fixing bug #1566280.
Fixed by moving the WaitForThreadShutdown call into Py_Finalize, so all
shutdown paths use it. I also tweaked the name to follow local helper
function conventions.
Martin, since
Adam Olsen [EMAIL PROTECTED] added the comment:
Oh, and the patch includes a testcase. The current test_threading.py
doesn't work with older versions, but a freestanding version of this
testcase passes in 2.1 to 2.4, fails in 2.5 and trunk, and passes with
the patch.
Thomas Dybdahl Ahle added the comment:
which means no global namespace access
Does that mean that you cannot use len and range in a Thread?
--
nosy: +lobais
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1722344
Changes by Amaury Forgeot d'Arc:
--
nosy: +amaury.forgeotdarc
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1722344
_
___
Python-bugs-list mailing list
Brett Cannon added the comment:
which means no global namespace access
Does that mean that you cannot use len and range in a Thread?
No, it means you have to be careful if you do. Shutting down properly
will take care of things. Otherwise you need to save a reference
locally (either on an
James Cooper added the comment:
Though these exceptions while shutting down are mostly harmless, they
are very noisy and must be squelched in a production application. Here
is the patch which we at Solido Design (www.solidodesign.com) are using
to hide the exceptions. Note that this doesn't
Brett Cannon added the comment:
I think the general idea of the problem has been stated, but I figured I
would state the official issue. When Python begins to shutdown it takes
each module and sets each variable in the global namespace to None. If a
thread has not terminated before the
Adam Olsen added the comment:
Py_Main calls WaitForThreadShutdown before calling Py_Finalize, which
should wait for all these threads to finish shutting down before it
starts wiping their globals.
However, if SystemExit is raised (such as via sys.exit()), Py_Exit is
called, and it directly
Adam Olsen added the comment:
To put it another way: SystemExit turns non-daemon threads into daemon
threads. This is clearly wrong. Brent, could you reopen the bug?
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1722344
Brett Cannon added the comment:
Hold on, why is that wrong? What if the threads block forever,
preventing shutdown? sys.exit() is not exactly some namby-pamby function
but a forced shutdown of the interpreter that should guarantee that the
interpreter quits. Changing its semantics now would take
Adam Olsen added the comment:
I disagree. sys.exit() attempts to gracefully shutdown the interpreter,
invoking try/finally blocks and the like. If you want to truly force
shutdown you should use os.abort() or os._exit().
Note that, as python doesn't call a main function, you have to use
Brett Cannon added the comment:
OK, I will re-open to see if some other core developer wants to take
this on, but personally I am passing.
--
resolution: wont fix -
status: closed - open
_
Tracker [EMAIL PROTECTED]
24 matches
Mail list logo
