homepage

As discussed in http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think that we shouldn't let EINTR leak to Python code: it should be handled properly by the C code, so that users (and the Python part of the stdlib) don't have to worry about this low-level historical nuisance.
For code that doesn't release the GIL, we could simply use this glibc macro:
# define TEMP_FAILURE_RETRY(expression) \
 (__extension__ \
 ({ long int __result; \
 do __result = (long int) (expression); \
 while (__result == -1L && errno == EINTR); \
 __result; }))
#endif
Now, I'm not sure about how to best handle this for code that releases the GIL.
Basically:
 Py_BEGIN_ALLOW_THREADS
 pid = waitpid(pid, &status, options);
 Py_END_ALLOW_THREADS
should become
begin_handle_eintr:
 Py_BEGIN_ALLOW_THREADS
 pid = waitpid(pid, &status, options);
 Py_END_ALLOW_THREADS
 if (pid < 0 && errno == EINTR) {
 if (PyErr_CheckSignals())
 return NULL;
 goto begin_handle_eintr;
 }
Should we do this with a macro?
If yes, should it be a new one that should be placed around Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS (like BEGIN_SELECT_LOOP in selectmodule.c) or could we have a single macro that would do both (i.e. release the GIL / reacquire the GIL, and try again in case of EINTR, unless a signal handler raised an exception)?
From a cursory look, the main files affected would be:
Modules/fcntlmodule.c
Modules/ossaudiodev.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/syslogmodule.c