[issue16560] Python sighandlers delayed for no reason
Zdenek Pavlas added the comment: > 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. Thanks, I see the problem. malloc() implements locking (when threads are enabled), but does not mask signals. When re-entered, this deadlocks. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue16560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16560] Python sighandlers delayed for no reason
Zdenek Pavlas added the comment: > This patch isn't safe Yes, it's broken. Does not work unless thread support was enabled, and locking initialized. There are probably other bugs, too. Not meant to be included, really. But IMO the correct implementation should work along these lines. > 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. > 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? -- ___ Python tracker <http://bugs.python.org/issue16560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16560] Python sighandlers delayed for no reason
New submission from Zdenek Pavlas: Quoting from "signal" module docs: # Although Python signal handlers are called asynchronously as far as the Python user is concerned, they can only occur between the “atomic” instructions of the Python interpreter. Yes, that's reasonable. # This means that signals arriving during long calculations implemented purely in C (such as regular expression matches on large bodies of text) may be delayed for an arbitrary amount of time. IMO, A does not imply B. Long computation in C with GIL released does not need to be atomic, as it happens "between" Python instructions. The thunk that's called asynchronously should preempt the C computation and issue a Python callback when possible. Otherwise, Python handlers are useless when interfacing C code. -- components: Interpreter Core files: trip-signal.patch keywords: patch messages: 176428 nosy: zdenek.pavlas priority: normal severity: normal status: open title: Python sighandlers delayed for no reason type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28133/trip-signal.patch ___ Python tracker <http://bugs.python.org/issue16560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
