Charles-François Natali added the comment: > the reason why signal handlers are called synchronously from the main loop is because you can't call arbitrary called on behalf of a signal handler: the must be async safe. > > > Could you elaborate, please? Suppose Python has called a C module. From Python's POV, an async signal is no different from a synchronous C=>Python callback. Both are safe.
No. Here, safe doesn't have anything to do with Python bytecode, or thread-safety. In C, you cannot call arbitrary code from a signal handler, the code must be async-safe (let's say reentrant): for example, if you call malloc() from within a signal handler, you can get a deadlock or a crash if the signal was received while the process was in the middle of an malloc() call. See https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlersfor example. So the bottom line is that *you can't call Python code from within a signal handler*. > > The proper way to do that would be to have a thread dedicated to signal management (like the Java VM does). > > Please, don't. Python is bloated enough already. > > > This patch is invalid (as is the issue). > > signal.alarm() and ctrl-c not working in modules is not a valid issue? Yes it is, but I don't think it can be solved without resorting to a dedicated signal management thread (which would also have the nice side effect of avoiding EINTR-related errors). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16560> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
