Darren J Moffat wrote:
> 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".
Erm.. I was thinking about a single Unix process...
> 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.
Umpf... this sounds a bit like an overkill (similar like hunting
sparrows with a MIM-104 Patriot SAM).
> Where would you expect the ulimit based policy to be setup ?
Within the application process itself or the calling process...
> 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 ?
IMO using projects(4), rctl etc. is an _overkill_. The idea is just to
lower the limit as "safeguard" without requiring "root" access (which
means projects(4) and SMF won't work... nor is it intended that the user
has to do some administrative stuff first).
Simple example:
-- snip --
function mythr
{
sleep 100
}
# main
builtin pthread_create
intefer i
integer -a tid
# set thread limit to 256
ulimit -T 256
for (( i=0 ; i < (Inf/10000.) ; i++ )) ; do
pthread_create -L -f mythr -t tid[i] || break
done
print -u2 "# waiting for children..."
wait -T "[EMAIL PROTECTED]"
print -u2 "# done."
exit 0
-- snip --
In this example the application launches threads... and by "accident"
the author has set the limit to (Inf/10000.) (=positive Infinite
dividided by 10000 is still infinite... uuuups... =:-) ) instead of a
plain value like 64. In this case the "ulimit -T 256" statement above
"kicks in" and prevents the application from launching threads in an
endless loop.
Note that limit needs to work even for plugin libraries (e.g. the script
may not launch threads itself but a plugin may itself use
|pthread_create()| directly without the interpreter's knowledge).
----
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
