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.
Here, safe doesn't have anything to do with Python bytecode, or
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.
So the bottom line is that *you can't call Python code from within a signal
> > 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>
Python-bugs-list mailing list