httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Shared memory in APR. (fwd)
Date Tue, 13 Jul 1999 13:35:59 GMT
On Tue, 13 Jul 1999, Michael H. Voase wrote:

> Dean Gaudet wrote:
> > 
> > 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.
> > 

Except that I wouldn't use wrappers in the mpm.  I would use a compile
time option.  I could easily add in the functions for shared memory and on
unix just not have the open child_shared function do anything.  And
specify that shared memory across non-related process doesn't work yet.
If I abstract it out right, this would be easy.

> Well that didnt take long ... This is an example of
> where macro based api mappings could assist. The mpm
> includes an api map which dictates what functions get
> called when a ap_* function is referenced. I settled
> on macros for this job since they wont add exrta
> overhead for their use. If an mpm writer gets really
> keen, they can even emulate apr in a direct api to
> OS mapping if someone wants to really squeeze the juice
> out of a platform. (great for speed , wastefull on
> code size unless done right ;)
> ( Please dont say 'apr provides this' . APR cant do
> an api on a 'per mpm' basis. Macro based api maps do.
> jeez even if you did use a per mpm wrapper library, a
> mapping could be just as easially substituted ;).

I don't see the need for an api macro.  mpm makes standard apr calls,
which do some magic and resolve to OS calls.  The on a per mpm basis thing
is IMO useless.  I thought the idea of an mpm, was that it didn't need to
do this sort of thing.  For example, shared memory, the windows mpm calls
ap_create_shared_mem() in the parent, and ap_open_shared_mem() in the
child.  The unix mpms call ap_create_shared_mem() in the parent.  APR then
decides the best method for creating shared memory based on how it was

Am I missing something?


Ryan Bloom
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.	

View raw message