One question that comes to mind would be interaction with userland
threading libraries. In such a case, ulimit has no way to control threads.
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.
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. (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.)
-- Garrett
Roland Mainz wrote:
> 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
>
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
