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!!)).

Since you specifically said application rather than process that easily 
maps to task.  Just run the application in its own task and set 
"task.max-lwps".

You can use the projects(4) system in Solaris to more easily manage the 
policy and even set which project the application runs in if it is 
started by SMF.

Where would you expect the ulimit based policy to be setup ?  Other than 
the fact that ulimit is cross platform why is ulimit a better inferface 
for this than the Solaris resource management framework exposed via 
rctl, projects etc ?

-- 
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to