Set Silo's DB_NFILES compile-time parameter at runtime

[aowen87]

Brian Rujiuz and Matt O'Brian requested this. Currently, Silo places an upper limit on maximum number of concurrently opened files. That number is 256 and it is set at compile time. First, I have no idea why 256 was chosen. It could be a value that was appropriate for machines that existed when Silo was first being written about 20 years ago. Most systems place an upper limit on total number of open files (descriptors) at 1024 or above. We can't get around that limit. But, Silo could be modified to use whatever the system limit as its own internal limit instead of a hard-coded 256.

-----------------------REDMINE MIGRATION----------------------- This ticket was migrated from Redmine. As such, not all information was able to be captured in the transition. Below is a complete record of the original redmine ticket.

Ticket number: 646 Status: New Project: VisIt Tracker: Feature Priority: Normal Subject: Set Silo's DB_NFILES compile-time parameter at runtime Assigned to: - Category: - Target version: - Author: Mark Miller Start: 03/08/2011 Due date: % Done: 0% Estimated time: 4.00 hours Created: 03/08/2011 06:52 pm Updated: Likelihood: Severity: Found in version: Impact: 2 - Low Expected Use: 2 - Rare OS: All Support Group: Any Description: Brian Rujiuz and Matt O'Brian requested this. Currently, Silo places an upper limit on maximum number of concurrently opened files. That number is 256 and it is set at compile time. First, I have no idea why 256 was chosen. It could be a value that was appropriate for machines that existed when Silo was first being written about 20 years ago. Most systems place an upper limit on total number of open files (descriptors) at 1024 or above. We can't get around that limit. But, Silo could be modified to use whatever the system limit as its own internal limit instead of a hard-coded 256.

Comments: