Date: Mon, 12 Jul 1999 11:50:58 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: Shared memory in APR. (fwd)
In-Reply-To: 
 <Pine.LNX.4.04.9907121344470.25921-100000@chosondo.raleigh.ibm.com>
Message-ID: <Pine.LNX.3.96dg4.990712112931.20623c-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
Status: O

Ryan I think you're trying to solve a different problem than Ralf was... 
Ralf's mm library is really a helper for all unix mpms which use fork(). 
I think you might want to take his library and use it as a basis on which
to build a "global shared memory API" into APR... that's really what
you're aiming at -- named shared memory which can be accessed from any
process which knows the name.

Our needs are frequently a subset of that (especially under unix).  But at
the moment I can't figure out the right way to abstract it... it's
something the MPM should be in control of, because the MPM allocates
threads.  But we want the actual code to live in APR.  It may be a matter
of APR providing many alternative methods to do this, and then we provide
MPM wrapper routines which select one of the APR methods.  Dunno. 

The problems I have with named shared mem are:

- access control (everything to do with access control is a portability
  nightmare... unix has users and groups, windows has ???, etc.)

- cleanup ... all the named shared mem methods under unix leave turds
  around when silly admins use kill -9 (admins do that)

So from my point of view, if I were implementing a unix multiprocess mpm I
would want ralf's mm library (anonymous shared mem), and not named shared
mem provided by APR. 

>From the module author's point of view (ssl session cache for example) 
they just want shared mem and synchronization primatives which work
between the threads which the MPM provides them.  This is anonymous shared
mem.

>From Ryan's point of view as APR author you want something which works
everywhere and has a single API.  As you've demonstrated this is named
shared mem.  (I think you're going to have "fun" with the access control
problem.) 

I think it's a case where reaching for the grail of portability is too
high -- we should aim somewhere else.  Let's aim for providing anon shared
mem through the MPM.  The need for a "attach child to shared mem" call
would be handled entirely inside the mpm, because it's the mpm that
decides if there are children.  So on win32 the mpm could call the kernel
functions directly to set up what it needs.  On unix the mpm could call
the mm library directly to set up what it needs. 

That's not to say that named shared mem is useless for us... it still has
a place in APR.  For example, people may want memory shared between an
external jvm process and apache. 

Dean

On Mon, 12 Jul 1999, Ryan Bloom wrote:

> 
> > Ok, but I've to admit that I still don't understand the issue completely.
> > When non-Unix platforms don't support fork() and instead some sort of thread
> > spawning, why is this bad for shared memory? Isn't APR more lucky then? I mean
> > the "shared memory" on these platforms we get for free, right? And on Unix we
> > use MM for "real" shared memory. 
> 
> As somebody else mentioned, Brian I think, I am not talking about thread
> spawning, but process spawning.  Take a look at Windows.  There is no fork
> call, but there is a CreateProcess call.  This doesn't duplicate the
> current process environment, but rather it creates an all new one.  I know
> of at least two other platforms that have this problem.  We need a way to
> reliably open shared memory in a child process that never shared data with
> it's parent.  If this is not possible with MM, then we need to
> re-implement MM for APR, IMO.  We support at least two platforms, where I
> do not believe fork is the correct call to make.   :-)
> 
> > 
> > I think the problem in our communication is that you want a shared mem
> > mechanism for APR which can be used between unrelated processed while I always
> > thought that we only deal with related processes, right? That's the fork+exec
> > goal you talked about, right? And is this _really_ necessary for APR? Hmmm..
> > then ok, it gets even hard under Unix, of course.
> 
> Every Unix shared memory call I know of has a way to do this.  It is
> simply a matter of designing things so that they work.  This is where I am
> getting hung up.  Basically, we need a MM_child_reopen_shared_memory() 
> call.
> 
> Ryan
> 
> 
> _______________________________________________________________________
> Ryan Bloom		rbb@raleigh.ibm.com
> 4205 S Miami Blvd	
> RTP, NC 27709		It's a beautiful sight to see good dancers 
> 			doing simple steps.  It's a painful sight to
> 			see beginners doing complicated patterns.	
> 
>