Re: additional sysconf variables
Matthew Fluet <[email protected]> Wed, 20 Jul 2011 16:21:16 -0400
| Newsgroups | gmane.comp.lang.ml.mlton.devel |
|---|---|
| Message-ID | <CAMrhFL58j1gV33aAq7eV_GYY-tNcH_dQ-u+ZV9f5wDUgizzOUA@mail.gmail.com> |
On Tue, Jul 12, 2011 at 8:41 PM, Christopher Cramer <[email protected]> wrote: > On Tue, Jul 12, 2011 at 04:56:22PM -0400, Matthew Fluet wrote: >> For the most part, we've been following the Single Unix Specification >> for the POSIX functionality. The currently supported sysconf >> variables correspond to those that are required by the specification >> (http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html). >> I'm not sure the best way of handling variables above and beyond the >> required set. Adding them piecemeal like this seems to be an onerous >> process. SML/NJ tries to mine <unistd.h> for _SC* names and generates >> a table specific to the target platform. > > Well... I don't think it's that onerous. I just copied the few extra ones > from the Linux docs. Checking the other platforms supported by MLton, > Solaris also has SC_NPROCESSORS_MAX, and then HPUX has a about a dozen > others. FreeBSD, OSX, AIX, OpenBSD, and NetBSD don't have any others > (most of them have just SC_NPROCESSORS_CONF and SC_NPROCESSORS_ONLN - > SC_NPROCESSORS_ONLN is in fact the one I want). > > Personally, I don't care about anything except Linux, but adding > SC_NPROCESSORS_MAX is not a big deal. The HPUX ones are mostly for > checking CPU characteristics, and I don't think they'll ever be useful > for a program written in SML. If you'd really like, I could write a > thing to do it the SML/NJ way though. Fair enough; the NPROCESSORS_{CONF,ONLN} and {,AV}PHYS_PAGES seem to be fairly widely supported. I've committed the patch. I will note that my glibc docs (for Fedora 15; also see http://www.gnu.org/software/libc/manual/html_node/Constants-for-Sysconf.html#Constants-for-Sysconf) include quite a few more _SC_* variables, though most of them seem to be of limited use (e.g., _SC_INT_MAX).