@ page 1469 line 45442 section sysconf objection [gwc OPEN_MAX&RLIMIT_NOFILE]
Problem:
Defect code : 1. Error
POSIX.1 has always said that the value returned by multiple calls to
sysconf(_SC_OPEN_MAX) in one process must not change over the lifetime
of the process. However, existing practice on several systems is that
after a call to setrlimit(RLIMIT_NOFILE, ...) the return value of
sysconf(_SC_OPEN_MAX) does change (to the new soft limit).
Before the merger of POSIX.1 and SUS this behaviour could perhaps have
been considered to be POSIX conforming, because setrlimit() was an
extension. However, now setrlimit() is part of POSIX.1-2001 it appears
that, as things stand now, this behaviour is not allowed.
There are several possible solutions, but they can be divided into
two types:
A. Reaffirm what the current spec. appears to say. Systems where
sysconf(_SC_OPEN_MAX) returns the RLIMIT_NOFILE soft limit would
have to be changed so that OPEN_MAX is an absolute limit,
independent of RLIMIT_NOFILE.
B. Change the spec. so that the value returned by sysconf(_SC_OPEN_MAX)
is allowed to change over the lifetime of the process. There are
several different variants of this, depending on how the value is
allowed to change, what extra requirements are made to ensure that
open fd's higher than the OPEN_MAX limit cannot exist, and whether
a means of finding out information about open fd's is provided.
For a type B solution, it is not enough just to change the spec. to
allow the value returned by sysconf(_SC_OPEN_MAX) to vary. On its own
this change would create a secondary problem whereby applications
could have an fd open (e.g. inherited from the parent) which is larger
than the maximum indicated by sysconf(_SC_OPEN_MAX). If this problem
is not addressed, applications will have no portable way to find a
reliable maximum fd value. Many existing applications assume that
sysconf(_SC_OPEN_MAX) is a reliable maximum and use it, for example,
to close all (unwanted) open fd's in situations where they cannot be
sure what fd's might be open.
Following discussions on the Austin Group mailing list, it is apparent
that there is a lot of support for a type B solution, but it looks
unlikely that consensus could be reached on the details of the best
solution. Therefore, I think that it would be best not to try and
specify any details - just make the minimum changes necessary to
resolve the problem, and leave the details up to the implementation.
Once the value returned by sysconf(_SC_OPEN_MAX) is allowed to vary,
the minimum extra requirement necessary to ensure that open fd's
higher than the OPEN_MAX limit cannot exist is simply to state that
sysconf(_SC_OPEN_MAX) must return a value greater than the highest
open fd. Implementations can comply with this either by having an
absolute OPEN_MAX limit (independent of RLIMIT_NOFILE), or by making
setrlimit() give an error if the new soft limit is lower than the
current highest open fd (plus 1), or by making sysconf(_SC_OPEN_MAX)
return the greater of the soft limit and (highest_open_fd + 1).
Action:
After "during the lifetime of the calling process" append ", except
that sysconf(_SC_OPEN_MAX) may return different values before and
after a call to setrlimit() which changes the RLIMIT_NOFILE soft
limit", with the new text shaded XSI.
After this sentence add (not shaded) "The value returned by
sysconf(_SC_OPEN_MAX) shall be either -1 or a value greater than
the highest currently open file descriptor."
|