STINNER Victor <victor.stin...@haypocalc.com> added the comment: > > - speed up the test: because dump_backtraces_later() has now a > > subsecond resolution, we can use sleep of 50 ms instead of 1 sec > > This is too short, there may be random failures on some slow buildbots. > IMO, 0.5s is the minimum you can use.
Ok, changed. > The docstring is outdated. fixed > It also seems the "cancel" option isn't > useful anymore, you could remove it and simplify the test. cancel is used by test_dump_tracebacks_later_repeat_cancel() to check that faulthandler.cancel_dump_tracebacks_later() did cancel the last dump_backtraces_later() request. > + process = script_helper.spawn_python('-c', code) > + stdout, stderr = process.communicate() > > Shouldn't you check the return code as well? Yes, except for fatal errors, because the C library exits with a non-zero exit code (e.g. 139 for a SIGSEGV on Linux). I added a check on the exit code. > + code = "\n".join(code) > > Again, I think it would make the code simpler and more maintainable if > you used triple-quoted strings instead of lists/tuples. Ok ok, done > When you launch a waiting thread in a subprocess, I think it's better to > set it in daemon mode so as to avoid blocking if the main thread raises > an exception. I doesn't know that. fixed > You have a "#ifdef MS_WINDOWS" in check_signum() but that function is > not compiled under Windows (it is inside "#ifdef FAULTHANDLER_USER"). Ah yes, the code became useless: removed -- Other changes: - faulthandler_fatal_error() calls the previous signal handler using raise(signum). Before, the signal was raised again because the same instruction was executed again, and it raised the same fault. But if the user sends manually a fatal signal to the process, the signal was ignored because of the fault handler (but the traceback was displayed). - use SA_NODEFER and SA_RESTART flags in enable() and register() - faulthandler_get_fileno() accepts fileno()==0 - cleanup the doc ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11393> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com