Signals and readline()

[Jeff Epler]

On Mon, 30 Apr 2001 21:01:47 -0700, Bob Alexander
 <balexander at rsv.ricoh.com> wrote:
> Note that what I'm discussing here is incorrect behavior when readline()
> is interrupted by a signal [...]

I apologize for my poor reading of your original post.  Once I read it again,
I was quickly able to reproduce the situation you're talking about.

I tend to agree that there's something wrong, given that f.read() *will*
raise an IOError in this situation, but f.readline() will not.

In Python 2.1, fileobject.c's "file_read" function reads in part:
                if (chunksize == 0) {
                        if (!ferror(f->f_fp))
                                break;
                        PyErr_SetFromErrno(PyExc_IOError);
                        clearerr(f->f_fp);
                        Py_DECREF(v);
                        return NULL;
                }
i.e., if fread returns 0 bytes, and ferror() says there was an error,
the errno, including -EINTR, is turned into a Python exception.  If ferror()
doesn't say there was an error, then it's merely EOF.

In "get_line",
                if (c == EOF) {
                        clearerr(fp);
                        if (PyErr_CheckSignals()) {
                                Py_DECREF(v);
                                return NULL;
                        }
                        break;
                }
If PyErr_CheckSignals returns an error (as far as I read the source, -1
or nonzero is returned for an error) *that* exception would be produced
from .readline().  But usually, if PyErr_CheckSignals has no signals pending,
or else the handlers run successfully, the 'break' will be hit and the
string will be returned as-is.

It seems to me that the code might need to read more like:
		if (c == EOF) {
			if (!ferror(fp)) break;
			clearerr(fp);
			Py_DECREF(v);
			if (PyErr_CheckSignals()) {
				return NULL;
			}
			PyErr_SetFromErrno(PyExc_IOError);
			return NULL;
		}	

but this isn't tested.....

Jeff