Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 1 May 2000 11:06:09 +0200
From: "Ralf S. Engelschall" <rse@engelschall.com>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/lib/apr/shmem/unix/mm aclocal.m4
Message-ID: <20000501110609.A88389@engelschall.com>
Reply-To: rse@engelschall.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.12i
Organization: Engelschall, Germany.


In article <Pine.LNX.4.21.0004301353180.7121-100000@koj.rkbloom.net> you wrote:

> This was my original argument, plus MM isn't portable to non unix
> platforms.  It doesn't suport names shared memory which is what Windows
> requires. 

Just for the record:

1. MM now works on non-Unix plaforms, too (BS2000, OS/390, BeOS, etc.)

2. I still do not understand why Win32 needs a shared memory library,
   because Win32 does not have fork(2). So what should MM provide under
   Win32? MM's goal is to supporting a consistent and convinient API for
   dealing with shared memory in pre-forked process environments.

3. The reason that MM doesn't support attaching to a shared memory
   segment from a different process is that this functionality cannot
   be provided across all platforms. MM is an abstraction library,
   so it provides the same functionality everywhere. I dislike APIs
   with feature test macros and other flags which indicate missing or
   available functionality.

> Other people argued that we shouldn't be re-creating work that
> has already been done for us.  I'm on your side Jim, I dislike having a
> requirement on outside projects.
> [...]
>> It seems to me, although I could be dead wrong, that APR is using
>> 'mm' (or is it 'MM') simply to determine things we already know,
>> from 1.3.x, and provide a nice interface. Is that right?
>> 
>> Is it possible to rip that out of 1.3.x?
>> 
>> My ONLY concern, and it's not MM/mm specific, is having to keep
>> up-to-date with various 3rd party packages that we rely on. At
>> the very least, it muddies the CVS logs :)   *duck* :) :)

A few points:

1. Be careful, MM is not just a "nice interface", Jim. It's a
   lower-level interface for abstracting the dealing with shared memory
   segments (mm_core.c) plus a higher-level malloc(2) style interface
   which provides a convinient way to work inside those shared memory
   segments (mm_alloc.c). Additionally the Autoconf environment in MM
   knows/determines more than the knowledge which was hard-coded in Apache
   1.3.

2. The group should not force theirself to not use any third-party
   packages just because they cause a little bit of CVS maintainance.
   If you look at the total amount of required manpower, you should
   recognize that a "cvs import" to the vendor branch is harmless
   compared to the maintainance effort the author of a package provides.
   Keep in mind that for every package the group maintains theirself
   they also have to provide own manpower. So both to reduce the
   required manpower and to avoid reinventing the wheels, the group
   should be keen on using externally maintained packages. CVS' magic
   vendor branches are a great feature for supporting those externally
   maintained packages. That's why I again suggest to do it this way:
   Place MM on the vendor branch in Apache 2.0, please.

3. The official/canonical _package_ name is "MM" ;)
   "mm" is just used for the tarball directory, API prefixes, etc

Yours,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com