> > On Sun, 02 Dec 2007 10:11:45 PST Richard L. Hamilton > wrote: > > > 6526924 kernel syscall Dis > setrlimit(2)/getrlimit(2) should support > RLIMIT_LOCKS, *_MEMLOCK and *_PTHREAD > > > Now, I can see _why_ the address space limit and > process size limit are one and the same: > > $ grep RLIMIT_AS /usr/include/sys/resource.h > > #define RLIMIT_AS RLIMIT_VMEM > > > but at the shell level, I wonder if it's not a > little misleading to have them both; it leaves the > > impression that they can be set individually. > > so which one should ksh drop when > RLIMIT_AS==RLIMIT_VMEM?
There's a lot of things I'd want to consider: * whether it's more cross-platform compatible to leave it the way it is, and perhaps just note in the man page that some of the entries aren't distinct * which is more common * whether any system implements both with distinct meanings (in which case, having both be synonyms on other systems might lead to confusion) * considering the latter two together, what would be most correctly and uniformly understood * what would be more compatible with bash So far, I haven't found a case where they're two different things. SUSv3 mentions RLIMIT_AS but not RLIMIT_VMEM: http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html but with respect to the shell, the only limit it seems to require is "ulimit -f", so I suppose all others are implementation dependent. APUE (2nd ed) says RLIMIT_VMEM is just an alias for RLIMIT_AS; so if they really are always the same if both present, perhaps just the RLIMIT_AS option should remain, using RLIMIT_VMEM if defined when RLIMIT_AS isn't. BTW, the only definition I've seen thus far of RLIMIT_SBSIZE sounds as if substituting the pipe buffer limit for it is incredibly misleading, to say the least. So I would think the socket buffer limit should be not supported for Solaris, until and unless something that at least reports an applicable value can be identified. > > Perhaps it might help if the output of ulimit -a at > the very least indicated the limits that > > were inherently read-only on a given platform; and > in the case of limits that were synonyms > > on a particular platform (such as address space and > process size on Solaris), indicated that also. > > And it's not at all clear to me what the sense of > treating pipe buffer size and socket buffer size > > as the same is; maybe on some *BSD systems, pipe() > is really socketpair(), but on Solaris, real > > pipe() calls result in a STREAMS based entity (onto > which one can push STREAMS modules, > > use the STREAMS rather than the socketpair() method > of passing file descriptors, etc). OTOH, > > I see that at least sometimes the ksh93 code maps > pipe() to socketpair(); not sure what the > > heck it's doing on Solaris. Still, if it isn't > mapping pipe() to socketpair(), then by using > > pathconf("/", _PC_PIPE_BUF) it's lying about the > socket buffer size, and if it is, it's lying about > both. > > > So in addition to adding some other limits, > rationalizing what ksh93 does with the existing ones > > on Solaris might not be a bad idea. (and the limit > that some systems have, RLIMIT_RSS, also > > sounds rather tempting if one's going to be > thinking of adding limits; I'd think it would be > > much more useful in most cases than RLIMIT_LOCKS, > for example) > > ksh93 ulimit is driven from this const table in > ksh93/data/limits.c > > const Limit_t shtab_limits[] = > { > "as", "address space limit", RLIMIT_AS, > 0, 'M', LIM_KBYTE, > ", "core file size", RLIMIT_CORE, 0, > 'c', LIM_BLOCK, > "cpu time", RLIMIT_CPU, 0, > 't', LIM_SECOND, > "data size", RLIMIT_DATA, 0, > 'd', LIM_KBYTE, > "file size", RLIMIT_FSIZE, 0, > 'f', LIM_BLOCK, > "number of file locks", RLIMIT_LOCKS, 0, > 'L', LIM_COUNT, > "locked address space", RLIMIT_MEMLOCK, 0, > 'l', LIM_KBYTE, > "number of open files", RLIMIT_NOFILE, > "OPEN_MAX", 'n', LIM_COUNT, > proc", "number of processes", RLIMIT_NPROC, > "CHILD_MAX", 'u', LIM_COUNT, > ipe", "pipe buffer size", RLIMIT_PIPE, > "PIPE_BUF", 'p', LIM_BYTE, > s", "resident set size", RLIMIT_RSS, > 0, 'm', LIM_KBYTE, > ize", "socket buffer size", RLIMIT_SBSIZE, > "PIPE_BUF", 'b', LIM_BYTE, > stack", "stack size", RLIMIT_STACK, > 0, 's', LIM_KBYTE, > hreads", "number of threads", RLIMIT_PTHREAD, > "THREADS_MAX", 'T', LIM_COUNT, > "vmem", "process size", RLIMIT_VMEM, > 0, 'v', LIM_KBYTE, > } > ; > > an iffe test defines RLIMIT_UNKNOWN and redefines any > RLIMIT_* not > supported on the local system to RLIMIT_UNKNOWN > > the only id that does not directly correspond to a > RLIMIT_* is "threads" vs RLIMIT_PTHREAD > > the limits with string entries, e.g., "nproc" => > "CHILD_MAX", defer to astconf(3) > (a library interface to confstr(2) sysconf(2) > pathconf(2) and getconf(1)) > so it would be possible to annotate "readonly" the > RLIMIT_UNKNOWN entries that defer to astconf() If the output has been changed in the past without major complaints (and if there's no commitment to keep it stable), I think it would be helpful to annotate in the ulimit -a output those that are readonly on a given platform; particularly since as you describe, it should be reasonably straightforward to do so. > to add a new limit that has a corresponding RLIMIT_* > or astconf() string, > simply add a new table entry > that will also take care of the --man/--html self- > documentation and table annotations > > the implementation uses the table index as a bitmask > so it is limited to sizeof(long)*8 entries Right - I had found the table but hadn't looked as far as to note the limit on the number of limits; that's good to keep in mind. Since I would hope that a long is at least 32 bits pretty much everywhere now, I suppose adding a _few_ would be ok, but going crazy would not. In any case, I don't think anyone is so much thinking of more limits as of implementing on Solaris a few more of the limits. I suppose that done reasonably, that would take care of itself with a recompile. This message posted from opensolaris.org
