httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <ron...@innovation.ch>
Subject Re: shmem in apr
Date Mon, 29 May 2000 19:48:43 GMT

On Mon, May 29, 2000 at 07:44:33AM -0700, rbb@covalent.net wrote:
> 
> > 1) I'm struggling with the following problem: graceful restarts
> >    don't immediately kill the children, but the pconf pool is
> >    cleared right away. This leads to havoc for shmem (unless I'm
> >    missing something obvious), as I now cannot use pconf in the
> >    post_config hook to allocate shmem (otherwise the shmem would
> >    be freed while processes are still using it during a graceful
> >    restart). What I really need a pool which is never cleared
> >    (e.g. pglobal), or a pool which is only cleared after all old
> >    children have died (this would provide a nice hook for certain
> >    cleanups).
> 
> How did 1.3 handle this?  It should have had the same problems.

No it didn't really, because there was no shared memory in 1.3.
Those that had somewhat related problems (e.g. mod_ssl) created
a new "top-level" pool (or standalone pool, or whatever the
expression was) - I didn't see any such thing anymore.

> > 2) I'm unclear on whether ap_get_shm_name and ap_set_shm_name
> >    need to be used or not, and how (they're currently both
> >    effectively nop's on unix and os/2). I'm assuming that if I
> >    call ap_shm_init in the parent process and propagate the
> >    ap_shmem_t handle to the children by virtue of the fact that
> >    they inherit the parents variables, then I don't need those
> >    functions. But is that true for all platforms? I.e. what is
> >    the safest model to assume? (sample pseudo code?)
> 
> They are needed.  Currently shmem in APR only supports shared memory
> between processes that are related by use of fork.  These functions allow

This is fine for me currently - I just want to be sure that there aren't
any systems out there which will require ap_get_shm_name/ap_set_shm_name
even with related processes. Hmm, I suppose nothing guarantees that an
mpm will create related processes (I'm thinking something like VMS's
"create /detach"), so maybe I need to use those anyway to be completely
portable?

> > 3) Shmem on M$: there aren't even any stubs for the shmem on this
> >    platform - should they be added? (and just do normal ap_palloc
> >    etc, since things seem to always be multithreaded, never
> >    multi-process on M$). Otherwise I have to litter mod_auth_digest
> >    with '#ifdef WIN32', which is ugly. If apr does want to support
> >    multi-process on M$ then using stubs won't work, of course. In
> >    that case it would seem to me that the mpm's ought to be
> >    providing a shmem abstraction too (i.e. as a module writer I
> >    don't want to care what the mpm process/thread model is, all I
> >    wan't is to be able to say 'give me memory which is shared
> >    between all threads and processes', which in the case of a
> >    threading-only mpm just degenerates to the usual ap_palloc and
> >    friends).
> 
> Nobody has had a need for shared memory on MS.  IMHO this does need to be
> added to Windows relatively soon.  Because of the way MS implements Shared
> memory the previous functions will be needed.  Also, you should almost
> never want to do #ifdef WIN32, APR has a feature macro
> APR_HAS_SHARED_MEMORY, so it is possible to just do #ifdef
> APR_HAS_SHARED_MEMORY.

Yes, I use that macro. However, I don't really need shared memroy on M$
currently, as the mpm is purely threaded (at leats that's the impression
I got). Or are you saying that I should always use shared memory, even
when using purely threaded mpm's? Hmm, I wonder what the performance
folks have to say here.

> As far as the memory management goes, we talked a
> long time ago about extending ap_palloc to work with pools, malloc, and
> shared mem, but nobody ever implemented anything.

That would be nice, but that's a different problem from what I'm trying
to solve right now.


  Cheers,

  Ronald


Mime
View raw message