* 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. "ulimit -T" could just be a thread count test in the language platform. > 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--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. That's fine, but it's not a justification for a new process-level-specific constraint (although it is why the resource controls are tied into the administrative model via project(4) (and, hence, smf(5))). - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
