On Wed, Dec 10, 2008 at 5:21 PM, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2008 at 6:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Several people already said (essentially) that: -1. I don't think such >> code should be added to the Python core, no matter how smart or correct >> it is. >> > > Looking up the thread, I don't see anyone taking such an extreme > position: never recover from SEGV even if it can be done 100% > correctly. The sentiment that I see and the one that I share is that > it is extremely difficult (and maybe impossible) to do correctly. > However, if someone comes up with a smart solution, I would be very > much interested to see it.
It is impossible to do in general, and I am -1 on any misguided attempts to do so. > While by the time you get a SIGSEGV, you process is likely to be > beyond recovery, I don't think the same applies to SIGFPE. No, it's as much about the context as it is the error. We could write our own floating point code that can recover from SIGFPE (which isn't portable, but still mostly doable), but enabling it for arbitrary third-party libraries is completely unsafe. Printing a stack trace and then aborting would be possible and useful though. > It may > also be possible to get rid of the arbitrary recursion limit on Linux > (I've heard this problem is solved on Windows) by being smart about > handling SIGSEGV. If we could calculate how much stack is left we'd have a much more robust way of doing recursion limits. I suppose this could be done by reading a byte from each page with a temporary SIGSEGV handler installed, but I'm not convinced you can't ask the platform directly somehow. I'd also be considered about thread-safety. > Finally, providing some diagnostic before exiting on hard errors is > not without precedent: I believe R has such a feature. It may be > worthwhile to compare Victor's approach to what is done in R. > > It may, however, be better to move further discussion to the tracker > (I understand that the patch is at > <http://bugs.python.org/issue3999>). -- Adam Olsen, aka Rhamphoryncus _______________________________________________ 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
