[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: Ok, fixed in r86214 (3.x), r86215 (3.1) and r86216 (2.7). Thanks for the patch! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: 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 > configu

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: 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 handl

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: 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

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: > ["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 tha

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: 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

[issue10311] Signal handlers must preserve errno

Amaury Forgeot d'Arc added the comment: > 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 exist

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: 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().

[issue10311] Signal handlers must preserve errno

Amaury Forgeot d'Arc added the comment: 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(). -- nosy: +amaury.forgeotdar

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: 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 wo

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: 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? -- nosy: +exarkun, loewis, pitrou stage: -> patch review versions: +Python 2.7, P

[issue10311] Signal handlers must preserve errno

New submission from Hallvard B Furuseth : 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 err