Date: Wed, 30 Jul 1997 07:21:55 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: hackers@freebsd.org Subject: Re: where to put access restriction for scheduling classes Message-ID: <199707301121.HAA00393@hda.hda.com> In-Reply-To: <199707300126.VAA16803@khavrinen.lcs.mit.edu> from Garrett Wollman at "Jul 29, 97 09:26:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
(Sorry that went out on -current. Redirecting to -hackers) > No shell should break as a result of defining a new resource limit. > Therefore, you should update setusercontext(3) and the two system > shells, and let the other shells fend for themselves. Shells won't break, but you won't be able to set the new resource using "limit" in unchanged shells. I'll do as you suggest - add RLIMIT_SCHEDULER and change csh and sh to support it. Then specific users can be permitted to change their process scheduler. I do have a related question - ptolemy for example uses 1003.4 process scheduling semantics for some simulations to ensure things run the way they want them to. I'd like per-process group scheduling so that one could ensure that a group of processes preempt each other without potentially hogging the CPU. This would be good both for this sort of simulation and for development of realtime systems. It is "half threaded": the process group as a whole would be fairly scheduled with other processes, but when it was readied the appropriate process would run, Does anyone have suggestions for how to specify this and how to implement this? Source should not have to be changed, so again an inherited per-process flag for real time flavor would be appropriate. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707301121.HAA00393>