Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!rutgers!husc6!ut-sally!std-unix From: std-unix@ut-sally.UUCP Newsgroups: comp.std.unix Subject: - copy of item posted to comp.unix.wizards Message-ID: <8261@ut-sally.UUCP> Date: Wed, 10-Jun-87 15:04:45 EDT Article-I.D.: ut-sally.8261 Posted: Wed Jun 10 15:04:45 1987 Date-Received: Tue, 16-Jun-87 01:15:45 EDT References: <3635@spool.WISC.EDU> <292@olamb.UUCP> Sender: std-unix@ut-sally.UUCP Reply-To: domo@sphinx.co.uk (Dominic Dunlop) Lines: 57 Keywords: NOFILES, S5R3, POSIX, 1003.1 Approved: jsq@sally.utexas.edu (Moderator, John Quarterman) Summary: POSIX is attempting to address this painful area From: domo@sphinx.co.uk (Dominic Dunlop) Agreed that finding out how many files you have to close in order to be sure you've closed them all is a pain on most implementations of UN*X. IEEE 1003.1 is attempting to address this and related issues (after they were highlighted by IBM and others). The current draft (#10) of 1003.1, which recently dropped stone-like through my (physical) mailbox, incorporates something that I and others cooked up at the April Toronto meeting. The affected section is 2.9, "Numerical Limits". As the changes have yet to be reviewed by the working group, they may well be thrown out or heavily modified later this month. Basically what the draft says is that things like OPEN_MAX, the maximum number of files that a process can have open at any given time, are defined in a header file, , as "bounded ranges". OPEN_MAX defines at compile time the "minimum maximum" number of files that a program can expect to be able to have open when it runs on a particular POSIX-conforming implementation (provided that the host system is not overloaded, that is, in this case, that it hasn't run out of space in its system open file or inode tables), while OPEN_MAX_CEIL defines the maximum number of files that any instance of this implementation could ever allow the program to have open. What this means to the programmer is that applications may be written so that they rely on being able to open OPEN_MAX files; so that they run better if they succeed in opening more files than that (although there's no point in trying if OPEN_MAX_CEIL are already open); and so that they can be sure that everything is closed (when spawning children, for example) if they for (i = 0; i < OPEN_MAX_CEIL; (void) close(i++)); Thanks for the idea of the bounded range are due to Terence Dowling of Rolm, who's not on the net. There's much more of this sort of thing in the draft standard. The alternative to this compile-time approach is a run-time library function which delivers either all possible information (in which case you get a fixed-size structure, and lose binary application compatibility if in subsequent releases of a particular POSIX-conforming implementation the amount of information returned increases); or requested items one at a time in some sort of union. If anybody would care to submit a proposal along these lines to the working group, it is likely that it would be gladly received. Copy relevant correspondence to John S Quarterman, moderator for comp.std.unix. He can be reached at ut-sally!std-unix. [ Or std-unix@sally.utexas.edu. -mod ] I am Dominic Dunlop Phone +44 628 75343 Sphinx Ltd. UKnet domo@sphinx.co.uk POSIX is a trademark of the IEEE Volume-Number: Volume 11, Number 61