Joerg Schilling wrote:
> Roland Mainz <[EMAIL PROTECTED]> wrote:
> > > Exactly how is ulimit -T portable didn't you already say it *does not*
> > > exist as part of POSIX and isn't available on other systems ?
> >
> > I've listed two other operating systems (AIX+IRIX) who already have this
> > kind of functionality (unfortunately with two slightly different names
> > (|RLIMIT_PTHREADS| vs. |RLIMIT_THREADS|)).
>
> The existence of such functions on other OS does not verify that they have
> been
> defined in a sane way. Linux e.g. also defines RLIMIT_MEMLOCK and the way it
> has
> been implemented, it makes rightful/privileged calls to
> mlockall(MCL_CURRENT|MCL_FUTURE) not working as expected.....
>
> The ulimit(1) POSIX documentation _only_ mentions "-f file bloks". All other
> functionality is beyond the ulimit(2) call.
The "ulimit" builtin of ksh and bash always used
|getrlimit()|/|setrlimit()| and not |ulimit()| - I don't even remebering
any _modern_ shell to use this call.
> 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.
> 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 ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL <currently fluctuating>
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
