This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients pitrou, sbt, vstinner
Date 2011-06-19.23:29:44
SpamBayes Score 2.0422026e-06
Marked as misclassified No
Message-id <1308526184.93.0.752288852931.issue12338@psf.upfronthosting.co.za>
In-reply-to
Content
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):).
History
Date User Action Args
2011-06-19 23:29:44vstinnersetrecipients: + vstinner, pitrou, sbt
2011-06-19 23:29:44vstinnersetmessageid: <1308526184.93.0.752288852931.issue12338@psf.upfronthosting.co.za>
2011-06-19 23:29:44vstinnerlinkissue12338 messages
2011-06-19 23:29:44vstinnercreate