#
# > On Fri, 5 Apr 1996, Phil Knaack wrote:
# > Try doing an "unlimit maxproc" (in csh) before running the forker... With
# > maxproc limited to 80 (the default, apparently), I got the same results as
# > you did. But "unlmit maxproc" raised the limit to 532, which made the
# > forker panic my machine with a "vm_map_entry_create: out of map entries". 
# > This is on a P5/100 with 48M ram, although it did the same thing when I 
# > had 16M...
#
#   Root could use the limit -h to prevent this. Limit -h sets the upper 
#   limit for the limits. 
#

This is a band-aid, though.  You should not be able to panic the system
like this.

"unlimit maxproc" should, at worst case, raise the proc limit to the max
USER procs with which the system is prepared to deal, and once the process
limit is reached, the system should definitely be refusing process creation,
not panic.

In short, the system should look at how many map entries it can possibly
create, and restrict maxproc accordingly.

Another point:  Although dynamic allocation/deallocation looks pretty on
paper, it's something that needs to be managed in a reasonable way, and
there are dependencies which need to be resolved, i.e. if you increase
your proc table size, per-process resources need to be allocated at
the same time, or an error needs to be returned and the operation not done.

If you're going to let EVERYTHING, including the kernel, make use of
dynamic allocation of core, you're going to have some serious problems
when spaces collide unless your memory management and resource allocation
routines have a good idea of what The Right Thing is to do; i.e., a process
may allocate a huge chunk of memory, and then someone may tweak the maxproc
space to make more process slots.  Which one of these is going to lose,
and why?

[yow, I'm rambling again.  Sorry.  I'll post more when my thoughts gain
 some more coherency.]


#  Peter

				--*greywolf;
--
When the government fails to meet the needs and wishes of its populace,
it is the right AND THE DUTY of the people to _abolish_ it, and start anew.
				-- Tom Jefferson (paraphrased)