homepage

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.

Obiouvsly you can find crashingMain.py and workingMain.py in the attached file.

Could you please reduce this to the shorted possible example that reproduces the problem?

Yes I could. You can find it attached.

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.

I vote for the latter.

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)

Fine w/ committing this Ask as-is ask. You are correct in the original intent of the code.

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-

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?

Can you please expand on "deeply different"?

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'

One issue with sys.exit() is that it only makes the current thread exit. Even when called in the main thread, the program will wait for non-daemon threads to finish. A closer equivalent to terminate() would be
os.kill(os.getpid(), signal.SIGTERM).
The problem with minCrashing.py on Windows is that you are inheriting from Queue which has a __reduce__ method. Your Process class is trying to use Queue.__reduce__ to pickle itself. You should really just do "self._queue = Queue()" instead of inheriting from Queue.

The docs were patched in changeset 9fa52478b32b, so I will close.