Message280848
| 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:28 | mjpieters | set | recipients:
+ mjpieters, doko, ggenellina, draghuram, marhar, r_mosaic, benjamin.peterson, eric.araujo, ralph.corderoy, nvetoshkin, Finkregh, jary, dankegel, Don Hatch |
| 2016年11月15日 14:26:27 | mjpieters | set | messageid: <1479219987.92.0.199011791216.issue1633941@psf.upfronthosting.co.za> |
| 2016年11月15日 14:26:27 | mjpieters | link | issue1633941 messages |
| 2016年11月15日 14:26:27 | mjpieters | create |
|