You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The corresponding information is hard to find, but Mac OS seems to intentionally provide these APIs (ulimit on the shell, resource.setrlimit in
Python) but ignore them. There is an article on this on lists.apple.com, which
is currently only available on the Wayback Machine:
The setrlimit() administrative limits are not enforced except for certain ones
which are enforcible in BSD code. Those which would require enforcement in Mach
code (VM-based enforcement or scheduler- based enforcement) are not currently
enforced at all.
These administrative limits were never intended to save the system from fragile
code; the way to do that is to make the code less fragile. They historically
date back to the days when CPU time and memory usage were billable resources,
and process accounting and system accounting were used on old timeshare machines
that were purchased by groups, such as several University departments, because
there was no way for a single University department to be able to afford its own
PDP-8. Today, they are basically knobs that have to be there so old code can be
ported, but which don't actually have to do anything, for the most part.
The limits are considered administrative, as they are not intended to permit the
creation of security policy dependencies, nor are they intended to mitigate
problems related to application memory leaks.
The following is the current(0) MacOS X resource limit support table:
------------- --------- ---------
Limit name Standard? Enforced?
------------- --------- ---------
RLIMIT_CPU YES NO
RLIMIT_FSIZE YES YES(1)
RLIMIT_DATA YES NO
RLIMIT_STACK YES YES(1)
RLIMIT_CORE YES YES
RLIMIT_AS YES NO
RLIMIT_RSS NO(2) NO
RLIMIT_MEMLOCK NO NO
RLIMIT_NPROC NO YES(3)
RLIMIT_NOFILE YES YES
------------- --------- ---------
(0) This table is subject to change.
(1) Not entirely correctly enforced; specifically, boundary conditions are
clipped before or after the boundary, rather than exactly at it.
(2) RLIMIT_RSS is a MACOS X-specific alias for RLIMIT_AS.
(3) Whether this limit is the upper bounds depends on current sysctl settings on
the machine.
To determine whether or not a limit is enforced by an OS, rather than using the
return code of setrlimit(), you must first use getrlimit() and compare the
result to RLIM_INFINITY; if it's RLIM_INFINITY, then you should not set a limit
(you can, but you will confuse child processes which call getrlimit() themselves
to check for enforcement, if you do).
The text was updated successfully, but these errors were encountered:
This call does not work on macOS/Darwin and will return an error which should be caught and ignored.
https://github.com/ESMCI/cime/blob/master/CIME/XML/env_mach_specific.py#L162:
If the resource node is identified as macOS, the resource.setrlimit() call should be skipped.
config_machines.xml
does not include an architecture or OS parameter, but one can useplatform
to identify the OS:Some context courtesy of Terry Lambert:
https://ai-fast-downward.dmi.unibas.ch/msg7484
The text was updated successfully, but these errors were encountered: