I suppose you could sort of emulate a per-process thread limit, within the C code of the shell, so that a ulimit shell command would (mostly) work as expected, although that might require the shell to do a settaskid() when exec'd, and also when returning from fork() in the child, so that the scope of a task is the same as that of a process (within shell processes, anyway). Then you'd just use getrctl()/setrctl() instead of getrlimit()/setrlimit() to implement that particular limit.
The main problem I have with that (as opposed to either a process.max-lwps rctl or an equivalent rlimit) is that if anything else is using tasks for its own purposes, this will probably not interact with that as expected/desired. So I think process.max-lwps may be a good idea. Ditto the corresponding getrlimit()/setrlimit(), _provided_ consensus is achieved elsewhere (and not simply by having OpenSolaris choose an existing example (like Linux, Irix, or AIX as previously cited) to be compatible with). I'm curious if there's an ARC or something corresponding to setrctl(2) saying "New process resource controls will not be made available with the rlimit interface". It seems reasonable to me that new rlimits should not be _initiated_ by OpenSolaris, since that is a less capable interface than a corresponding rctl. But if there were already to be a comparable rctl _and_ some consensus among other OSs (or better, that plus maybe making it on to at least an Austin Group draft) on a new rlimit, I don't see the benefit in being too compulsive about not adding it without being required to by a fully formalized standard. Since either rctl or rlimit are typically (and perhaps have to be, to be secure) kernel-enforced, but a user-level thread may or may not correspond to a kernel-level entity, I think the terminology for any new rlimit should reflect that, making it (a) optional in the case of totally user-level thread implementation (which may not be to many people's liking, but AFAIK might still be possible in a standards-compliant way) and (b) that it applies to kernel-level scheduling entities, which if supported, correspond to pthreads of scope PTHREAD_SCOPE_SYSTEM. Thus, process.max-lwps (not max-threads), and perhaps RLIMIT_SYSTHREADS or somesuch (a cursory examination of SUSv3 didn't turn up the term LWP, although I certainly didn't try all possible searches). All of which is to say that I just don't see why OpenSolaris should get into the business of driving the establishment of a standard enabling this, for the sake of facilitating the development of multithreaded interpretive languages. But once even informal (but likely to become formal without being mangled) consensus is already established, if the process.max-lwps were in place, I can't imagine why adding the corresponding rlimit should have to be a big deal. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
