Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit : > There should be at least one reviewer with an established track record > of being interested/knowledgable in the POSIX APIs and cross-platform > aspects of it.
Functions used by the fault handler: - write() - PyUnicode_Check() - PyFrame_GetLineNumber() - DebugBreak() (Windows, in debug mode, only) - abort() - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE() - PyUnicode_Check(), PyFrame_Check() - PyFrame_GetLineNumber() - _Py_atomic_load_relaxed() - _PyThreadState_GetFrame() I suppose that all *Py*() functions are POSIX compliants. DebugBreak() is specific to Windows. Only write() and abort() have to be POSIX compliant. According to Linux manual pages: - abort() conforms to SVr4, POSIX.1-2001, 4.3BSD, C89, C99. - write() conforms to SVr4, 4.3BSD, POSIX.1-2001 -- Functions used by the other parts of the patch: - signal() or sigaction()+sigemptyset() - (optional) sigaltstack() - PyMem_Malloc(), PyMem_Free() - Py_GETENV() - (optional) getpid(), kill() (used by the tests) signal() conforms to C89, C99, POSIX.1-2001. So I don't see any function incompatible with POSIX. (Don't read old versions of my patch, read the latest version) -- About the cross-platform question: it looks like SIGFPE fault is not catchable on Windows. I only tried Linux and Windows, but there are a unit test for each signal and we have 60+ buildbots with various platforms. Can't we wait for the buildbot results? > > Well, Python already does (and also apparently messes with other things > > such as FPU state), so that's a separate issue altogether. > > Not at all. Some signal handlers are more likely to interfere with the > the rest of the application than others. Python installs its own SIGINT handler. I think that a SIGINT handler is more intrusive than a SIGSEGV or SIGILL handler. Victor _______________________________________________ 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
