From owner-cvs-sys  Sun Aug 27 09:38:58 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id JAA26719
          for cvs-sys-outgoing; Sun, 27 Aug 1995 09:38:58 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id JAA26711
          ; Sun, 27 Aug 1995 09:38:42 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA23170; Mon, 28 Aug 1995 02:35:18 +1000
Date: Mon, 28 Aug 1995 02:35:18 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199508271635.CAA23170@godzilla.zeta.org.au>
To: CVS-commiters@freefall.FreeBSD.org, cvs-sys@freefall.FreeBSD.org,
        joerg@freefall.FreeBSD.org
Subject: Re: cvs commit: src/sys/i386/conf LINT
Sender: cvs-sys-owner@FreeBSD.org
Precedence: bulk

>  Modified:    sys/i386/conf  LINT
>  Log:
>  Add a comment that a user with many open windows under X might need to
>  bump CHILD_MAX.
>  
>  Closes PR # conf/708: CHILD_MAX set rather low...
>  
>  Submitted by:	careilly@monoid.cs.tcd.ie

Aargh.  The user should just increase the resource limit (`limit maxproc
nnn' or `unlimit maxproc' in csh; `ulimit -u nnn' in bash; not supported
in sh :-().

Changing CHILD_MAX in the kernel breaks any applications that depend on
its fixed value (not many; perhaps only POSIX test suites that check that
CHILD_MAX works :-).  Changing the limit at runtime breaks these
applications too, but at least it only applies to the current process
tree.

Changing CHILD_MAX everywhere would break binary compatibility.  So does
using limit at runtime, but the damage is limited.

Similarly for OPEN_MAX.

Bruce