Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <04d601c187f5$3688b230$96c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: "Brad Nicholes" <BNICHOLES@novell.com>,
	<dev@httpd.apache.org>
References: <sc1f2427.045@prv-mail20.provo.novell.com>
Subject: Re: cvs commit: httpd-2.0/server/mpm/netware mpm_netware.c
Date: Tue, 18 Dec 2001 12:51:28 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Brad Nicholes" <BNICHOLES@novell.com>
Sent: Tuesday, December 18, 2001 12:10 PM


> Bill,
>     I guess I don't follow your comment.  mpm_netware.c still follows
> the same scheme as other MPM's in that it respects HARD_SERVER_LIMIT, it
> just makes sure that it is never anything other than 1.  All references
> to the scoreboard always use 0 for the server slot and a thread id for
> the thread slot.  If somebody recompiles the code with HARD_SERVER_LIMIT
> set to 0, which is ridiculous, then they get way they deserve.  If they
> set it to something greater than 1 then they are just wasting memory
> because it is physically impossible for NetWare to start more than one
> instance in the same name space.  Is there something else I should be
> concerned about.

No... just that given the choice between testing a constant 1 and the
HARD_SERVER_LIMIT, I'd go with HARD_SERVER_LIMIT.

If you want to test HARD_SERVER_LIMIT == 1 at startup, that's cool.  Simply,
if there were ever a bug in the HARD_SERVER_LIMIT macro on Netware, you want
your MPM to share the same bugs as any 3rd party modules that also try to
use it.  Essentially, by using HARD_SERVER_LIMIT instead of the const 1 value,
you are putting another brick in the way of another bug breaking out of
the project :)

Bill