Stephen Hahn wrote:
> * Roland Mainz <[EMAIL PROTECTED]> [2008-06-07 01:45]:
> > Is anyone here interested to sponsor an ARC case to add a limiter for
> > the number of threads to "ulimit" and the matching
> > |setrlimit()|+|getrlimit()| system calls ?
>
> You are actually proposing a new resource control, "process.max-lwps".
> There's some internal history on this, which I can dig up if needed,
> but the summary is that, since there are constraints on this resource
> at the task, project, and zone level, why is a process level
> constraint also needed? (Each of these constraints is evaluated
> during the creation of an LWP.)
It is needed to guard applications from launching too many threads by
accident. Our actual problem right now is that we add thread support to
a shell (and other thread-capable scripting languages have similar
problems), e.g. something like $ sh -c 'function mythr { sleep 100 ; } ;
builtin pthread_create ; integer tid ; pthread_create -L -f mythr -t tid
; wait -T ${tid} ; exit 0' # should work in the future. And like the
nproc limit we need something to guard scripts (or binary plugins which
themselves launch threads) from running an out-of-control loop which
spawns threads in an endless loop (without affecting other processes in
the same process group (even child or parent processes!!)).
> In any case, I would not be interested in seeing any of the
> setrlimit(2)/getrlimit(2)/ulimit(2) interfaces extended, although I
> have no comment on how one might choose to represent access to such a
> constraint in a shell. I suppose if the semantics matched some other
> OS's capabilities and those capabilities were widely invoked, then
> there's a more interesting discussion to have...
At least IRIX has |RLIMIT_PTHREAD| and AIX has |RLIMIT_THREADS|
(grumpf... two slightly different names for exactly the same stuff)
which is represented by the "ulimit"'s "-T" flag and someone from SuSE
wrote a patch for Linux to get |RLIMIT_PTHREAD| (e.g. it's there but
much discussion in the LKM can be avoided if >= 2 Unix versions have
that resoruce control and not only two with minor naming differences).
Technically the idea to add this to the Solaris resource control stuff
sounds Ok but it won't help for other platforms since the Solaris
resource limits are specific for Solaris and (AFAIK) no other operating
system has adopted it yet. IMO we would have better chanches to
encourage other operating systems to use a "natural extension of
|setrlimit()|+|getrlimit()|, e.g. |RLIMIT_PTHREAD| than "you must
implement Solaris resource limits" to get this stuff working.
Anyway... my point is to build this on top of a standards function like
|setrlimit()|/|getrlimit()| (see
http://opengroup.org/onlinepubs/007908799/xsh/getrlimit.html) in the
hope we can get others into the boat, too. Technically we may even ask
the standards folks to get this added to the POSIX stuff in the future
if we can meet the requirement for this (e.g. >= two sample
implementations (which we could easily meet (see above))).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
