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/prototype011/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 result... which
is a really bad bug.
> > 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.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
