Greetings:
Please forgive me if this is the wrong place for this post. I couldn't find a
more acceptable forum. If there is one, please point me in the right
direction.
I am part of a small team writing a table-driven automated testing framework
for embedded software. The tables, which contain rows of keywords and data
that drive the testing, are stored as plain-text "Comma-Separated Value" or
.csv files. Each table can call other tables, which means that multiple files
may be open at a time.
The framework includes a Parser class. The program takes the name of the
top-level table as a parameter, creates an instance of the Parser and passes
the table name to it. The Parser instance opens the .csv file with that name,
reads each line of the file (row of the table) and takes the appropriate
action. When it encounters a row referencing another table, it creates a new
Parser instance and passes it the name of the new table, suspending its own
operation until the new Parser instance completes.
In this way, a tree of Parser instances is created, each with a single open
file object. (BTW, recursive and circular references are not allowed.) When
each Parser instance comes to the end of its table, the instance is explicitly
destroyed, presumably destroying any objects it holds, AND closing its open
file.
Because of the nature of the framework and the testing we do, this Parser tree
never gets very tall: four or five levels at the most. The same table may be
invoked dozens or hundreds of times, however, with different sets of data each
time.
This is where things go wrong. After about 500 table invocations, the
framework starts refusing to process any more tables, responding with the
following error:
[Errno 24] Too many open files: 'HostCommandDevNotReady.csv'
We can correct the behavior by explicitly closing each Parser's table file
object before exiting the Parser code. This indicates that Python is failing
to free up some file-related internal resource when the Parser object is
destroyed. This behavior occurs on Python 2.3 and 2.4 for Windows, but not on
Python 2.3 for Linux, and not on the Windows version of Python2.5.
This is why I didn't just post a report to Bug Tracker: the problem seems to
have been fixed. I did search through the archive of Windows related bugs, but
found no mention of this type of a bug. What I want to know is:
* has anyone else encountered a problem like this,
* how was the problem corrected,
* can the fix be retro-fitted to 2.5 and 2.4?
Thanks in advance for any information you can provide.
Regards,
Barry
[EMAIL PROTECTED]
541-302-1107
________________________
We who cut mere stones must always be envisioning cathedrals.
-Quarry worker's creed
--
http://mail.python.org/mailman/listinfo/python-list
