Stephen Hahn wrote: > * Roland Mainz <[EMAIL PROTECTED]> [2008-06-09 10:23]: > > 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. > > For the application case, OS support isn't needed, as the application > (or the language platform) could count the threads directly.
Erm... this works for an application which has full control of all consumers of the POSIX thread API but a shared library has no such control. Similar problems arise if you allow binary plugin to run their own threads and then have to deal with them (JAVA's JNI was such a case where the JAVA developers did not expect that anyone would try to be that mad and use |fork()| or |pthread_create()| or mess around with signals in plugin code... the real world showed that customers will try to do exactly that... ;-/ ). > "ulimit -T" could just be a thread count test in the language > platform. This won't work - see above... > > 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). > > On the other hand, if you're making the assumption that the library is > opaque, you actually don't know whether the library's thread > requests are needed for correct operation or not Erm... it's up to the author to set a correct limit for as argument for "ulimit -T <numthreads>" ... > --you're taking on the > role of a deployer, because your goal is to set a bound on one > application to prevent its impact on the remainder of the system, and > you've decided that that goal is more important than the possibility > of program completion. Right... but the author of the application still has to explicitly use "ulimit -T <numthreads>" and _hopefully_ thinks about this a bit. > That's fine, but it's not a justification for a new > process-level-specific constraint What would be in your opinion a good justification ? > (although it is why the resource > controls are tied into the administrative model via project(4) (and, > hence, smf(5))). What do you mean with that ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL <currently fluctuating> (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
