classification
Title: self.terminate() from a multiprocessing.Process raises AttributeError exception
Type: Stage:
Components: Versions: Python 3.2
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: jnoller Nosy List: 5houston, asksol, jnoller
Priority: normal Keywords: patch

Created on 2010-02-27 19:58 by 5houston, last changed 2010-11-20 17:29 by 5houston.

Files
File name Uploaded Description Edit
pythonProcBug.tar.bz2 5houston, 2010-02-27 19:58 It contains a piece of code to reproduce the problem.
minCrashing.py.bz2 5houston, 2010-10-06 19:05
i8028.patch asksol, 2010-11-02 15:16
Messages (12)
msg100191 - (view) Author: (5houston) Date: 2010-02-27 19:58
Try to execute "python -OO crashingMain.py" using python 3.1 or 3.1.1.

It creates and starts 5 SendingProcess(es).
SendingProcess inherits from multiprocessing.Process and multiprocessing.queue.Queue.

Each process starts a loop.

In the meanwhile the main, calling close() method of each SendingProcess, puts 1 into each SendingProcess and each SendingProcess, when it self.get(s) it, calls self.terminate.

This causes a AttributeError exception for each SendingProcess.

workingMain.py instead does not call close() method.
It calls directly the terminate method of each SendingProcess.
msg100192 - (view) Author: (5houston) Date: 2010-02-27 20:01
Obiouvsly you can find crashingMain.py and workingMain.py in the attached file.
msg118016 - (view) Author: Ask Solem (asksol) (Python committer) Date: 2010-10-05 15:09
Could you please reduce this to the shorted possible example that reproduces the problem?
msg118075 - (view) Author: (5houston) Date: 2010-10-06 19:05
Yes I could. You can find it attached.
msg120229 - (view) Author: Ask Solem (asksol) (Python committer) Date: 2010-11-02 15:16
It seems that Process.terminate is not meant to be used by the child, but only the parent.

From the documentation:

  "Note that the start(), join(), is_alive() and exit_code methods
  should only be called by the process that created the process object."

Either terminate() should be added to this list,
or terminate should be patch to call sys.exit in a child process.

I vote for the former, so I attached a doc patch.
msg120331 - (view) Author: (5houston) Date: 2010-11-03 17:37
I vote for the latter.
msg120345 - (view) Author: Ask Solem (asksol) (Python committer) Date: 2010-11-03 20:38
Since you can't specify the return code, `self.terminate` is less flexible than `sys.exit`.

I think the original intent is clear here, the method is there for the parent to control the child.  You are of course welcome to argue otherwise.

By the way, I just read the code and noticed that it handles SystemExit well, and supports using it to set the return code:

    class X(Process):
        def run(self):
            if not frobulating:
                raise SystemExit(255)
msg120505 - (view) Author: Jesse Noller (jnoller) * (Python committer) Date: 2010-11-05 14:54
Fine w/ committing this Ask as-is ask. You are correct in the original intent of the code.
msg120942 - (view) Author: (5houston) Date: 2010-11-11 11:13
If you will choose the former way, I think it would be better to write in the "multiprocessing.Process" documentation that sys.exit is the function to use to break the process execution inside itself, but maybe it would be better to wrap sys.exit with a new "multiprocessing.Process" method:
multiprocessing.Process.exit([arg]) for example.
Maybe it would be better to modify the sys.exit documentation too.
From "Exit from Python" to "Exit from python process which it is called in".
Or, finally, you could modify "multiprocessing.Process.terminate" in this way (using pseudo-code):

self.terminate():
    if caller is self: sys.exit()
    else: -the current code-
msg121501 - (view) Author: (5houston) Date: 2010-11-19 06:03
Hi.
I tried my code (minCrashing.py) in windows using python 3.1.2, 2.3alpha4 and 3.1.3rc1
The behaviour is deeply different from linux 3.1.2.
I think it's a bug.
What do you think about it?
msg121536 - (view) Author: Jesse Noller (jnoller) * (Python committer) Date: 2010-11-19 15:27
Can you please expand on "deeply different"?
msg121691 - (view) Author: (5houston) Date: 2010-11-20 17:29
Yes, I can.
This is the minCrashing.py output from python3.2a4 in windows XP sp3:

Traceback (most recent call last):
  File "c:\Python32\lib\multiprocessing\process.py", line 233, in _bootstrap
    self.run()
  File "c:\Python32\lib\multiprocessing\process.py", line 87, in run
    if self._target:
AttributeError: 'Process' object has no attribute '_target'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\Python32\lib\multiprocessing\forking.py", line 349, in main
    exitcode = self._bootstrap()
  File "c:\Python32\lib\multiprocessing\process.py", line 249, in _bootstrap
    sys.stderr.write('Process %s:\n' % self.name)
  File "c:\Python32\lib\multiprocessing\process.py", line 137, in name
    return self._name
AttributeError: 'Process' object has no attribute '_name'
History
Date User Action Args
2010-11-20 17:29:515houstonsetmessages: + msg121691
2010-11-19 15:27:45jnollersetmessages: + msg121536
2010-11-19 06:03:085houstonsetmessages: + msg121501
versions: + Python 3.2, - Python 3.1
2010-11-11 11:13:195houstonsetmessages: + msg120942
2010-11-05 14:54:31jnollersetmessages: + msg120505
2010-11-03 20:38:38asksolsetmessages: + msg120345
2010-11-03 17:37:505houstonsetmessages: + msg120331
2010-11-02 15:16:12asksolsetfiles: + i8028.patch
keywords: + patch
messages: + msg120229
2010-10-06 19:05:315houstonsetfiles: + minCrashing.py.bz2

messages: + msg118075
2010-10-05 15:09:51asksolsetnosy: + asksol
messages: + msg118016
2010-02-27 23:54:17benjamin.petersonsetassignee: jnoller

nosy: + jnoller
2010-02-27 20:01:345houstonsetmessages: + msg100192
2010-02-27 19:58:325houstoncreate