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'