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 mjpieters
Recipients Don Hatch, Finkregh, benjamin.peterson, dankegel, doko, draghuram, eric.araujo, ggenellina, jary, marhar, mjpieters, nvetoshkin, r_mosaic, ralph.corderoy
Date 2016-11-15.14:26:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1479219987.92.0.199011791216.issue1633941@psf.upfronthosting.co.za>
In-reply-to
Content
This bug affects all use of `file.__iter__` and interrupts (EINTR), not just sys.stdin.

You can reproduce the issue by reading from a (slow) pipe in a terminal window and resizing that window, for example; the interrupt is not handled and a future call ends up raising `IOError: [Errno 0] Error`, a rather confusing message.

The Mercurial community is switching away from using direct iteration over this bug; Jun's excellent analysis is included and enlightening:

   https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090522.html

The fix is to use

    interrupted = ferror(f->f_fp) && errno == EINTR;
    // ..
    if (interrupted) {
        clearerr(f->f_fp);
        if (PyErr_CheckSignals()) {
            Py_DECREF(v);
            return NULL;
        }
    }

and check for interrupted == 0 in the chunksize == 0 case after Py_UniversalNewlineFread calls, as file_read does, for example, but which readahead doesn't (where the only public user of readahead is file_iternext).
History
Date User Action Args
2016-11-15 14:26:28mjpieterssetrecipients: + mjpieters, doko, ggenellina, draghuram, marhar, r_mosaic, benjamin.peterson, eric.araujo, ralph.corderoy, nvetoshkin, Finkregh, jary, dankegel, Don Hatch
2016-11-15 14:26:27mjpieterssetmessageid: <1479219987.92.0.199011791216.issue1633941@psf.upfronthosting.co.za>
2016-11-15 14:26:27mjpieterslinkissue1633941 messages
2016-11-15 14:26:27mjpieterscreate