is open(...).read() a resource leak?

[Benjamin Rutt]

If I did the following in an infinite loop, would the host system/user
account soon run out of file descriptors? (I'm thinking no, since I'd
imagine that a file object has a __del__-like method that will call
close() automatically since it goes out of scope):

open('/home/rutt/.bashrc,'r').read()

Can anyone confirm that I'm right in seeing (1) the file object's
actual destructor is below and seems to call a close method if not
already done (at the <-- indicated lines) and (2) the method table
that makes this method the destructor? Both are in
Objects/fileobject.c in python sources.

(1)
static void
file_dealloc(PyFileObject *f)
{
if (f->f_fp != NULL && f->f_close != NULL) { <----
Py_BEGIN_ALLOW_THREADS
(*f->f_close)(f->f_fp); <----
Py_END_ALLOW_THREADS
}
Py_XDECREF(f->f_name);
Py_XDECREF(f->f_mode);
Py_XDECREF(f->f_encoding);
drop_readahead(f);
f->ob_type->tp_free((PyObject *)f);
}


(2)
PyTypeObject PyFile_Type = {
PyObject_HEAD_INIT(&PyType_Type)
0,
"file",
sizeof(PyFileObject),
0,
(destructor)file_dealloc, /* tp_dealloc */ <----
0, /* tp_print */
0, /* tp_getattr */
0, /* tp_setattr */
0, /* tp_compare */
(reprfunc)file_repr, /* tp_repr */
0, /* tp_as_number */
[...]

Thanks,

 

[Fredrik Lundh]

If I did the following in an infinite loop, would the host system/user
account soon run out of file descriptors? (I'm thinking no, since I'd
imagine that a file object has a __del__-like method that will call
close() automatically since it goes out of scope):

open('/home/rutt/.bashrc,'r').read()

under CPython, this is not a problem (the reference counting system will
make sure that file handles are reclaimed as fast as new ones are opened).

under an arbitrary Python implementation, it may be a problem, especially
if the implementation doesn't trigger a collection if it runs out of handles (that
can be seen as a bug, though...).

</F>

 

[Benjamin Rutt]

under CPython, this is not a problem (the reference counting system will
make sure that file handles are reclaimed as fast as new ones are opened).

It would be reclaimed immediately, correct? (As opposed to waiting
for the next file-open call or some later time). In my understanding
of CPython gc and reference counting, only the cyclical objects will
be lazily/periodically reclaimed in a scheduled fashion, while all
non-cyclical objects are reclaimed immediately when their last
incoming reference decrements the count to 0.

under an arbitrary Python implementation, it may be a problem,
especially if the implementation doesn't trigger a collection if it
runs out of handles (that can be seen as a bug, though...).

OK, makes sense, thank you.