At Tuesday 9/1/2007 22:03, Carroll, Barry wrote:
The first assumption was correct: the file object is destroyed. The
second assumption is apparently incorrect: the file handle is not
released when the associated object is destroyed. These 'orphaned'
file handles build up and when the OS handle limit is reached, "too
many open files" errors show up.
I've tried with 2.3.4 something like this:
flist = []
for i in range(5000):
fn = 'test%04.4d.tmp' % i
print fn
f = open(fn,'w')
flist.append(f)
# f.close()
Without the last close(), I get an error on iteration 509 like you;
adding the close(), I can create the 5000 file instances without
problems. So it seems that Python *does* release the file handle.
> On Python 2.5 you can use the new `with` statement.
>
Not only that, the file errors don't appear when we run our
program/table combination under 2.5. I can't explain the
difference, unless the work done to implement the 'with' statement
has an impact outside the scope of that feature. In any event, it
does us no good. Other constraints on the test system require us to
stick with Python 2.3, at least for the present.
My advise would be (as others have already suggested) to not *assume*
anything and put a print statement when you think you close the file.
Perhaps that code fragment is never executed! Or perhaps there is
*another* place where you open a file and never close it (a logfile
perhaps? it doesnt have to be a different file each time). Someone
already suggested to use Filemon to trace the file operations; you
can also use Process Explorer to inspect the open file handles (both
tools available from SysInternals).
--
Gabriel Genellina
Softlab SRL
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas
--
http://mail.python.org/mailman/listinfo/python-list
