Garrett D'Amore wrote:
>
> One question that comes to mind would be interaction with userland
> threading libraries. In such a case, ulimit has no way to control threads.
When I'm thinking about threads then I'm thinking about the stuff
provided by the kernel and not any stuff like JAVA's "greenthreads" etc.
Maybe we should name the limit "RLIMIT_PTHREAD" to point to the
|pthread_*()|-stuff...
> I have mixed feelings personally about implementing this, without some
> kind of standards activity occurring simultaneously. Just expecting
> everyone to "follow me" is probably not a great way to gain widespread
> acceptance.
If we reach consens here we may want to add Don Cragun to the thread...
> The other questions are, given the existance of resource controls, and a
> very light-weight threads implementation, does such a resource
> limitation even make sense? Certainly ulimit seems like a half-baked
> solution compared to proper resource controls.
For now I can't imagine any other API which has widespead usage and I do
not have the resources to start a standardtisation process for moving
Solaris resource controls to POSIX (which will AFAIK meet serious
resistance without doing some redesign). And I disagree with "half-baked
solution" - the purpose is to prevent a "runaway" operation and AFAIK
|setrlimit()|+|getrlimit()| are good enough for that purpose.
> (Threads are resource
> consumers themselves, and the dependency should, IMO, be expressed on a
> limit of the consumed resources -- memory and CPU cycles, rather than
> some middle-man value like thread or process counts. Though I suppose
> the pool of lwp IDs globally is itself a finite resource, though I doubt
> its possible to hit that limit without running into other more limiting
> ceilings first -- like virtual memory.)
Right... but AFAIK this is far beyond the scope of a simply "number of
threads" limit ("KISS" design, please). Please don't mutate this RFE
(I'm still suffering from the shock how the "64bit coreutils+bash" ARC
case mutated into something political... ;-( ) ...
----
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
