* Roland Mainz <[EMAIL PROTECTED]> [2007-02-20 18:44]: > Stephen Hahn wrote: > > I would really rather not see the setrlimit(2) emulation in the > > resource control framework extended. > > Why ?
Because the (soft, hard) semantic in the setrlimit emulation code is... unpleasant to map to each control we might envision. Because the controls you are discussing are already implementation specific, and not necessarily the best choices for restricting resource consumption on a system. (Because I wrote it, and don't believe it's the most important piece of code to improve in OpenSolaris right now?) > > Perhaps an OpenSolaris-specific > > function in ksh93 to call setrctl(2) directly would be more > > appropriate. (Plus we don't have process-level controls for some of > > these resources today.) > > There are two problems: > 1. "ulimit" works per-process and these controls should IMO be available > per-process. Fine, but that's an RFE against the related kernel subsystems. Putting a limit on consumption has performance impact, if only for the bookkeeping. > 2. setrctl(2) is currently a non-standard API setrctl(2) is a documented and committed OpenSolaris API. Programs wishing to offer resource management functionality for multiple platforms need to accept that such functionality must already handle the non-uniformity of approaches taken on various platforms. > I really like to see at least RLIMIT_PTHREAD implemented to have a limit > which prevents applications from running a threaded version of the > fork()-bomb. We already have task.max-lwps, project.max-lwps, and zone.max-lwps. An RFE to add a process equivalent probably exists, although it seems superfluous given the set of controls on this resource already available to the administrator (via project(4) and prctl(1)) and developer (via setrctl(2)). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
