httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <>
Subject Re: cvs commit: apache-2.0/src CHANGES
Date Fri, 02 Jun 2000 12:17:04 GMT

On Thu, Jun 01, 2000 at 04:57:15PM -0700, Manoj Kasichainula wrote:
> On Thu, Jun 01, 2000 at 01:30:12PM -0700, wrote:
> > I still like the idea of MPM's that don't have (or need) shared
> > memory creating their own stub functions that just call the regular
> > memory allocation functions.  I was going to suggest they call the
> > pool allocation functions, but they aren't a one for one map, and
> > the regular allocation functions are.  Or, and this may make the
> > most sense, don't let platforms not implement the shared memory
> > routines.  Just make platforms that don't really need the shared
> > memory routines use malloc/free inside their
> > ap_shm_malloc/ap_shm_free.  The problem with the last design is that
> > is ties Apache and APR very tightly, which I hate.  :-)
> +1. In fact, I'd go a step further, and say that MPM's should export
> functions to allocate server-wide memory. For multiprocess MPMs on
> OSes with shared memory, they would call ap_shm_*. For uniprocess
> MPMs, they call malloc/free.

So far I completely agree, and would've done it already myself had
I more time...

> For multiprocess MPMs on OSes without
> shared memory (I haven't paid enough attention to know if there are
> any of these), don't implement the functions at all, and modules that
> need these functions will fail to build (as they should).

No, I don't want mod_auth_digest to fail to build in this case, because
it can very well deal with this case and run with reduced functionality.
There needs to be a feature macro MPM_HAS_SHARED_MEM or something (where
"shared mem" need not be real shared mem in the case of uniprocess
MPM's) in addition.

> As the good man said, a level of indirection will solve all your
> problems.




View raw message