[issue16560] Python sighandlers delayed for no reason

[Zdenek Pavlas]

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 

___
___
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

[Charles-François Natali]

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 

___
___
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]

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 

___
___
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

[Charles-François Natali]

Charles-François Natali added the comment:

> Not sure if this would be a feature request or a bugfix

That would rather be a bug injection.

This patch isn't safe: 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.

The proper way to do that would be to have a thread dedicated to signal 
management (like the Java VM does).

This patch is invalid (as is the issue).

--
nosy: +neologix

___
Python tracker 

___
___
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

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Not sure if this would be a feature request or a bugfix, specially in the 
python 2.7 case :).

--
nosy: +jcea
versions: +Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com