> Roland Mainz <[EMAIL PROTECTED]> wrote:
>
> > > Given the fact that even the current set of ksh93
> ulimit(1) options is beyond
> > > the {get!set}rlimit() set,
> >
> > Erm... the current code in
> >
> svn://svn.genunix.org/on/branches/ksh93/gisburn/protot
> ype011/usr/ _only_
> > uses |getrlimit()|/|setrlimit()| for the "ulimit"
> builtin.
>
> You should have a look at the code....
>
> $ ulimit -a
> address space limit (kbytes) (-M) unlimited
> core file size (blocks) (-c) unlimited
> cpu time (seconds) (-t) unlimited
> data size (kbytes) (-d) unlimited
> file size (blocks) (-f) unlimited
> locks (-L) not supported
> locked address space (kbytes) (-l) not supported
> nofile (-n) 256
> nproc (-u) 29995
> * pipe buffer size (bytes) (-p) 5120
> + resident set size (kbytes) (-m) unlimited
> * socket buffer size (bytes) (-b) 5120
> stack size (kbytes) (-s) 10240
> threads (-T) not supported
> process size (kbytes) (-v) unlimited
>
> *) Not related to get/set-rlimit() at all
>
> +) unsupported in get/set-rlimit() since 20 years.
> BTW ksh93
> seems to call getrlimit(RLIMIT_CPU, to get the
> e result... which
> is a really bad bug.
...and not new, either - Solaris 8 dtksh does that too.
BTW, AFAIK pipe buffer size control is not available on Solaris at all
(some systems do have this); and the socket buffer size probably also lies,
due to how ksh93 implements it for Solaris at present.
See http://opensolaris.org/jive/thread.jspa?threadID=46158&tstart=75
where this has been discussed before. (Yaybe pushing bufmod onto a
STREAMS pipe and performing the appropriate ioctls could approximate
setting pipe buffer size, but I have my doubts.) getconf PIPE_BUF / will
report a fixed value of 5120. See
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/fs_subr.c#482
where the kernel simply returns a constant from sys/param.h
> > > I see no reason to require new functinality to be
> > > implemented using {get!set}rlimit().
> >
> > How else should it be implemenetd then without
> littering the codebase
> > with Solaris-specific code ?
>
> First, the implementation needs to made correct.
>
> Then you would need to understand that ulimit already
> uses other ways to get/set
> the data. I see no problem to add just another
> exception to the ones that
> already exist.
Which is what I meant when I'd previously said one could fake up a
thread limit by doing settaskid() and manipulating task.max-lwp,
subject to the limitation that doing that on a per-task basis in place
of the missing ability to do it on a per-process basis could get fouled up
if something else was explicitly managing tasks.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
