Martin v. Löwis <mar...@v.loewis.de> added the comment: > But what is so special about the win32_ExitProcess() function, the > changes apply only for the actual ExitProcess() call (not the duration > of the rest of the forked job.
Two things: a) it's not really likely that it uncovers an application bug that people would run into, and b) there is no other way to suppress the problem. > That looks like a forced fix to a specific problem, not a generic > buildbot-friendly feature. In case such a bug comes up again, it is important that no popup will trigger again > SetErrorMode(), btw, is inherited by child processes: Correct. With -n restored to test.bat, that can be taken out. > For _CrtSetReportMode, don't we want to channel the output to stderr, > rather than the debugger output? That would work as well (and perhaps better) > Also, let's not forget, that parameter validation will throw up > dialogue boxes in a release mode too() (in DEBUG an assert is thrown in > to the mix as well, which is what you are silencing) Yes - because I know you want these error boxes, we only added it in debug mode (because that's what the buildbots use) > If we are doing this for the benefit of buildbot, then why don't we do > it in python.exe? We could add an --unattended flag or something > similar which would silence or redirect any interactive notifications > we can think of. There is the -n flag for regrtest already. Unfortunately, there is no easy way to pass it to the subprocess. I'm opposed to a new command line flag, because there are already so many of them. I would hope that multiprocessing could pass the CRT flags to subprocesses (see the subject of this report). Somebody would have to implement it, though. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5619> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com