R. David Murray added the comment:
You should open a new issue. Bonus if you can supply a unit test and patch :)
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
Memeplex added the comment:
I would like to reopen this issue because of the following, very related,
behavior. Try this:
```
import multiprocessing as mp
import time
def g():
time.sleep(100)
def f():
mp.Process(target=g).start()
1/0
mp.Process(target=f).start()
```
It won't
Changes by Memeplex carlosjosep...@gmail.com:
--
versions: +Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
___
___
Memeplex added the comment:
http://bugs.python.org/issue24948
I posted a tentative solution there.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 2863d9273abd by Antoine Pitrou in branch '3.2':
Issue #13812: When a multiprocessing Process child raises an exception, flush
stderr after printing the exception traceback.
Antoine Pitrou pit...@free.fr added the comment:
Patch now committed, thanks.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
Charles-François Natali neolo...@free.fr added the comment:
I propose applying the following patch.
The test looks good to me (except we don't remove TESTFN explicitely,
but I'm not sure it's really necessary).
As for the patch, couldn't we put all the file stream flushing in one place?
Antoine Pitrou pit...@free.fr added the comment:
Updated patch sanitizing the various flushes done on exit, as per
Charles-François's recommendation. Also removes TESTFN explicitly.
--
Added file: http://bugs.python.org/file24311/mpstderrflush2.patch
Charles-François Natali neolo...@free.fr added the comment:
LGTM.
(I just noticed a bug in Rietveld: when one selects expand 10 after,
the line right after that marker appears duplicated in the new view).
--
___
Python tracker rep...@bugs.python.org
Jon Brandvein jon.brandv...@gmail.com added the comment:
Patch looks fine. I like the use of finally for the flush.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
___
Antoine Pitrou pit...@free.fr added the comment:
I also found that under Python 2.x, even a low-level exit like
os._exit or multiprocessing.win32.ExitProcess, called from within a
user-level function in the child, caused flushing.
The difference is the following:
- Python 2.x uses C stdio
Antoine Pitrou pit...@free.fr added the comment:
I propose applying the following patch.
We could open a separate issue to suggest exit = sys.exit under Windows (it
doesn't seem to break any tests).
--
keywords: +patch
nosy: +neologix
stage: test needed - patch review
Added file:
Jon Brandvein jon.brandv...@gmail.com added the comment:
Regarding the patch: I'd also like to see sys.stdout.flush() and
sys.stderr.flush() between exitcode = self._boostrap() and exit(exitcode)
in /Lib/multiprocessing/forking.py :: main(). (The extra stderr flush would be
for symmetry with
Jesse Noller jnol...@gmail.com added the comment:
There's already a bug / pending patch for this behavior here:
http://bugs.python.org/issue8713
No need to take it to -ideas.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
But I observe that unless I explicitly flush stdout and stderr before
terminating, the output is lost entirely, even if the exit is not
abnormal. This isn't the desired behavior, is it?
Indeed that's a bit surprising. Which Python version
Jon Brandvein jon.brandv...@gmail.com added the comment:
On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not under
2.7.1. On Linux, I have not reproduced the problem on versions 2.6.3, 2.7.2,
3.1.1, or 3.2.2.
So to summarize:
- It seems there should be a stderr flush call
Antoine Pitrou pit...@free.fr added the comment:
Le dimanche 22 janvier 2012 à 17:58 +, Jon Brandvein a écrit :
Jon Brandvein jon.brandv...@gmail.com added the comment:
On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not
under 2.7.1. On Linux, I have not reproduced the
Jon Brandvein jon.brandv...@gmail.com added the comment:
I've been looking over this package some more, and in particular,
/Lib/multiprocessing/forking.py. There's plenty I don't understand, and I do
have questions, if you would be willing to indulge me.
I see that both the unix and windows
Jon Brandvein jon.brandv...@gmail.com added the comment:
Some more information: When I write to a new file created by open(), all
versions flush correctly. However, if I reassign sys.stdout to that file,
Python 3.x does not (again, under Windows). I wonder what it is that causes
these other
Jon Brandvein jon.brandv...@gmail.com added the comment:
It turns out the file output was flushing due to garbage collection. When I
created and held a global reference to it, it ceased to flush. Clearly,
reassigning sys.stdout also held a reference to it. So it wasn't any kind of
special
Changes by Terry J. Reedy tjre...@udel.edu:
--
nosy: +jnoller
stage: - test needed
versions: -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
___
New submission from Jon Brandvein jon.brandv...@gmail.com:
When a child process exits due to an exception, a traceback is written, but
stderr is not flushed. Thus I see a header like Process 1:\n, but no
traceback.
I don't have a development environment or any experience with Mecurial, so I'm
Jon Brandvein jon.brandv...@gmail.com added the comment:
(Er, that should be /Lib/multiprocessing/process.py :: Process._bootstrap of
course.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13812
23 matches
Mail list logo
