[issue15881] multiprocessing 'NoneType' object is not callable
New submission from Chris McDonough:
The symptom is an exact duplicate of the symptom reported in the following
(closed) issue:
http://bugs.python.org/issue9775
The issue is also related to the following other issues:
http://bugs.python.org/issue4106
http://bugs.python.org/issue9205
http://bugs.python.org/issue9207
To reproduce the symptom driving the patches that will be attached to this
issue:
git clone git://github.com/pypa/pip.git
cd pip
/any/python setup.py dev
/any/python setup.py test
You can either wait for the entire test suite to finish or you can press ctrl-C
at any time (the tests take a long time). In either case, a traceback like the
following will be printed to the console.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in
_run_exitfuncs
func(*targs, **kargs)
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py",
line 284, in _exit_function
info('process shutting down')
TypeError: 'NoneType' object is not callable
Error in sys.exitfunc:
Traceback (most recent call last):
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in
_run_exitfuncs
func(*targs, **kargs)
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py",
line 284, in _exit_function
info('process shutting down')
TypeError: 'NoneType' object is not callable
>From what I understand in other issues, multiprocessing.util._exit_function
>shouldn't actually be called *after* the containing module's globals are
>destroyed (it should be called before), but this does indeed happen.
Patches will be attached that anticipate the symptom and prevent a shutdown
error. One will be attached for Python 2.7 branch, the other for the Python
tip. Each causes functions that are called at shutdown time to keep a
reference around to other functions and globals used within the function, and
each does some checks for the insane state and prevents an error from happening
in this insane state.
--
components: Library (Lib)
messages: 170003
nosy: mcdonc
priority: normal
severity: normal
status: open
title: multiprocessing 'NoneType' object is not callable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue15881>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15881] multiprocessing 'NoneType' object is not callable
Chris McDonough added the comment: Patch for tip. -- keywords: +patch Added file: http://bugs.python.org/file27142/shutdown_typeerror-tip.patch ___ Python tracker <http://bugs.python.org/issue15881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15881] multiprocessing 'NoneType' object is not callable
Chris McDonough added the comment: 2.7 branch patch. -- Added file: http://bugs.python.org/file27143/shutdown_typeerror-27.patch ___ Python tracker <http://bugs.python.org/issue15881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641] asyncore delayed calls feature
Chris McDonough added the comment: I am the developer of Supervisor (http://supervisord.org) which depends on (and extends) Medusa 0.5.4, which itself depends on some implementation details of pre-2.6 versions of asynchat (e.g. "ac_out_buffer"). I need to make sure Supervisor works with Python 2.3, 2.4, and 2.5, as well as Python 2.6. To do so, I intend to just ship the Python 2.5 version of asyncore/asynchat along with Medusa 0.5.4 and Supervisor in the next Supervisor release; straddling the asynchat stuff would just be too hard here. I don't know of any other consumers of Medusa other than Zope and Supervisor, so maybe Medusa should just ship with its own version of asyncore and asynchat forever from now on; I'm certainly not going to take the time to "fix" Medusa to forward port it to the 2.6 version of asynchat. I might argue that in retrospect the the current implementation of asynchat might have been better named "asynchat2", as the changes made to it seem to have broken of its major consumers. But we can work around it by just forking, I think. -- nosy: +mcdonc ___ Python tracker <http://bugs.python.org/issue1641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1573931] WSGI, cgi.FieldStorage incompatibility
Chris McDonough added the comment: Although the current WSGI 1.0 spec (http://www.python.org/dev/peps/pep-0333/) still indicates that implementing the size argument to readline is not required, effectively, it is and has been for several years. Stalling on a WSGI 1.1 spec has caused a spec change to be delayed. See also http://www.mail-archive.com/web-...@python.org/msg02494.html -- nosy: +mcdonc ___ Python tracker <http://bugs.python.org/issue1573931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
