Email List: Xaustin-review-lX
[All Lists]

RE: Defect in XBD limits.h

To: "'Geoff Clare'" <yyy@xxxxxxxxxxxxx>, <yyyyyyyyyyyyyyy@xxxxxxxxxxxxx>
Subject: RE: Defect in XBD limits.h
From: "Mark Funkenhauser" <yyyyyyyyyyyyy@xxxxxxxxxx>
Date: Tue, 4 Nov 2003 23:40:28 -0500
Isn't  {OPEN_MAX} a "runtime invariant" value ?
Doesn't this mean that the value of {OPEN_MAX}
cannot change during the lifetime of a process ?

If so, then how is it possible for a 'fd' to be greater than 
the current value of {OPEN_MAX} ?

mark

> -----Original Message-----
> From: Geoff Clare [mailto:yyy@xxxxxxxxxxxxx] 
> Sent: Tuesday, November 04, 2003 1:20 PM
> To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Defect in XBD limits.h
> 
> 
> @ page 248 line 8724 section limits.h objection [gwc OPEN_MAX]
> 
> Problem:
> 
> Defect code :  1. Error
> 
> The description of OPEN_MAX on the limits.h page is:
> 
>    {OPEN_MAX}
>       Maximum number of files that one process can have open at any
>       one time.
> 
> This is fine if OPEN_MAX is a constant defined in limits.h, but if
> the limit varies then I believe the description does not match
> current behaviour in the case where a file descriptor >= OPEN_MAX is
> already open.
> 
> I do not think current systems keep an independent count of open file
> descriptors.  They search for the first available file descriptor and
> if they reach OPEN_MAX without finding one then they give an EMFILE
> error.  The standard does not currently allow this behaviour - it
> requires an EMFILE error when OPEN_MAX file descriptors are open,
> even if some file descriptors numbered less than OPEN_MAX are still
> available.
> 
> The problem can be solved either by changing the description of
> OPEN_MAX, the description of EMFILE in the "Error Numbers" section
> of XSH6, and the descriptions of EMFILE for individual functions in
> XSH6; or by forbidding the situation where a fd >= OPEN_MAX is open.
> Note that I proposed the latter in March 2002 (along with the change
> that allowed sysconf(_SC_OPEN_MAX) to return different values before
> and after a call to setrlimit() that changes RLIMIT_NOFILE), and it
> was rejected then.  However, this new aspect of the "fd >= OPEN_MAX"
> problem has come to light since then and so was not taken 
> into account.
> 
> Action:
> 
> Either
> 
> 1. Change "Maximum number of files that one process can have open at
> any one time" to "A value one greater than the maximum value that the
> system may assign to a newly-created file descriptor".
> 
> On XSH6 page 24 lines 964-965 change:
> 
>    "[EMFILE]
>        Too many open files. An attempt was made to open more than the
>        maximum number of file descriptors allowed in this process."
> 
> to:
> 
>    "[EMFILE]
>        File descriptor too large.  An attempt was made to open a file
>        descriptor with a value greater than or equal to {OPEN_MAX},
>        [XSI] or greater than or equal to the soft RLIMIT_NOFILE limit
>        for the process (if smaller than {OPEN_MAX}).[/XSI]"
> 
> and make suitable changes to the EMFILE descriptions on individual
> function pages.
> 
> Or
> 
> 2. Insert before XSH6 page 1469 line 45443, "The value returned by
> sysconf(_SC_OPEN_MAX) shall be either -1 or a value greater than
> the highest currently open file descriptor."
> 

<Prev in Thread] Current Thread [Next in Thread>