homepage

multiprocessing.util._eintr_retry is only used to wrap select.select, but it fails to recalculate timeouts.
Also, it will never retry the function it wraps because of a missing "import errno".
I think it would be better to just implement the retrying version of select directly.

subprocess._communicate_with_select() retries select.select() on EINTR: it recomputes timeout before each call.
while self._read_set or self._write_set:
 timeout = self._remaining_time(endtime)
 if timeout is not None and timeout < 0:
 raise TimeoutExpired(self.args, orig_timeout)
 try:
 (rlist, wlist, xlist) = \
 select.select(self._read_set, self._write_set, [],
 timeout)
 except select.error as e:
 if e.args[0] == errno.EINTR:
 continue
 raise
 ...
It has a similar code for select.poll().
asyncore.poll() handles EINTR: it just returns.
> I think it would be better to just implement the retrying version
> of select directly.
It would be nice to share more code between subprocess and multiprocessing, but I don't know where such code should be moved. Create a new module just for one function is stupid. Handling EINTR is a common problem when managing subprocesses.
subprocess has a _eintr_retry_call() function.
multiprocessing has a @_eintr_retry decorator handling supporting more error types (use except (EnvironmentError, select.error):).

_eintr_retry is currently unused. The attached patch removes it.
If it is retained then we should at least add a warning that it does not recalculate timeouts.

> _eintr_retry is currently unused.
AFAICT it's still used in forking.py.

SocketServer has been changed to restart select() on EINTR, but it doesn't recompute the timeout.

> SocketServer has been changed to restart select() on EINTR,
> but it doesn't recompute the timeout.
See issue #7978.

Note that socketserver's timeout is not really important: it's just used for a polling loop, with a default of 0.5 seconds.

_eintr_retry was removed by 99ef4501205b.