[ksh93-integration-discuss] ksh93 ulimit, was Re: How can I search for my own bugreports ?

[Richard L. Hamilton]

> 
> 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