Message85059
> 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. |
|
Date |
User |
Action |
Args |
2009-04-01 17:53:34 | loewis | set | recipients:
+ loewis, kristjan.jonsson, ocean-city, jnoller, asvetlov |
2009-04-01 17:53:33 | loewis | link | issue5619 messages |
2009-04-01 17:53:32 | loewis | create | |
|