homepage

Signal handlers that can change errno, must restore it.
I enclose a patch for <2.7, 3.2a3>/Modules/signalmodule.c
which also rearranges the code to make this a bit easier.
The patch does if (errno != save_errno) errno = save_errno;
instead of just errno = save_errno;
in case it's less thread-safe to write than to read errno,
which would not surprise me but may be pointless paranoia.
I don't know what needs to be done on non-Unix systems,
like Windows' WSAError stuff.

This is a good idea IMO. It would be better if you minimized style changes, so that the patch is easier to review.
Also, is the while loop around write() necessary here?

Parser/intrcheck.c:intcatcher() should do the same. Covered in Issue
10312.
Antoine Pitrou writes:
> This is a good idea IMO. It would be better if you minimized style
> changes, so that the patch is easier to review.
I'm afraid the un-rearranged code would be fairly ugly, so I cleaned
up first. Single exit point.
> Also, is the while loop around write() necessary here?
Whoops, I'd forgotten I did that too, it was on my TODO list to
check if Python makes it unnecessary by making write restartable.
I don't remember if that's possible to ensure on all modern Posixes

This issue is not really relevant on Windows:
- signals are actually run in a new thread specially created.
- errno is a thread-local variable; its value is thus local to the signal handler, same for WSAGetLastError().

Amaury Forgeot d'Arc writes:
> This issue is not really relevant on Windows:
> - signals are actually run in a new thread specially created.
> - errno is a thread-local variable; its value is thus local to the
> signal handler, same for WSAGetLastError().
Nice. Then I suggest a config macro for whether this is needed.
Either a test for windows, or an autoconf thing in case some Unixes
are equally sensible. (Linux isn't, I checked.)

> Nice. Then I suggest a config macro for whether this is needed.
> Either a test for windows, or an autoconf thing in case some Unixes
> are equally sensible. (Linux isn't, I checked.)
I'm quite sure that all Unixes invoke signal handlers in some existing thread. So even if errno is thread-local, it needs to be saved and restored.
OTOH this is really a micro optimization.

Amaury Forgeot d'Arc writes:
> OTOH this is really a micro optimization.
["this" = only saving/restoring errno when needed]
True, but practically nothing is officially safe to do in signal
handlers, so it's good to avoid code which can be avoided there.
If one can be bothered to, that is.

> ["this" = only saving/restoring errno when needed]
> True, but practically nothing is officially safe to do in signal
> handlers, so it's good to avoid code which can be avoided there.
> If one can be bothered to, that is.
I think it is extremely unlikely that mutating errno in a signal handler is unsafe (after all, the library functions called from that handler can mutate errno too: that's the whole point of the patch IIUC). Adding some configure machinery for this seems unwarranted to me.

By the way, I'd like to clear out a potential misunderstanding: the function you are patching doesn't call Python signal handlers in itself (those registered using signal.signal()). It only schedules them for later execution. If you want to save errno around Python signal handlers themselves, PyErr_CheckSignals must be patched as well.

Antoine Pitrou writes:
> By the way, I'd like to clear out a potential misunderstanding: the
> function you are patching doesn't call Python signal handlers in itself
> (those registered using signal.signal()). (...)
Good point - I'm talking C signal handlers, not Python signal handlers.
> If you want to save errno around Python signal handlers
> themselves, PyErr_CheckSignals must be patched as well.
Probably not. I don't know Python's errno conventions, if any, but
it's usually a bug to use errno at any distance from the error. The C
code near the error can save errno if it wants it later. It can't do
that around C signal handlers, since those can get called anywhere.

Antoine Pitrou writes:
> I think it is extremely unlikely that mutating errno in a signal handler
> is unsafe (after all, the library functions called from that handler can
> mutate errno too: that's the whole point of the patch IIUC). Adding some
> configure machinery for this seems unwarranted to me.
Fine by me.

Ok, fixed in r86214 (3.x), r86215 (3.1) and r86216 (2.7). Thanks for the patch!