On Thu, Dec 11, 2008 at 10:08 AM, Jeffrey Yasskin <jyass...@gmail.com> wrote: > On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner > <victor.stin...@haypocalc.com> wrote: >> But if -as many people wrote- >> Python is totally broken after a segfault, it is maybe not a good idea :-) > > While it's true that after a segfault or unexpected longjmp, there are > no guarantees whatsoever about the state of the python program, the > program will often just happen to work, and there are at least some > programs I've worked on that would rather take the risk in order to > try to shut down gracefully. For example, an interactive app may want > to give the user a chance to save her (not necessarily corrupted) work > into a new file rather than unconditionally losing it. Or a webserver > might want to catch the segfault, finish replying to the other > requests that were in progress at the time, maybe reply to the request > that caused the segfault, and then restart. Yes there's a possibility > that the events around the segfault exposed some secret internal data > (and they may do so even without segfaulting), but when the > alternative is not replying to the users at all, this may be a risk > the app wants to take. It would be nice for Python to at least expose > the option so that developers (who are consenting adults, remember) > can make their own decisions. It should _not_ be on by default, but > something like sys.dangerous_turn_C_crashes_into_exceptions() would be > useful.
Trying to recover (or save work etc.) is incredibility unpredictable, though. It could very well end up making the situation worse! I'm -1 on putting this in the core. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com