httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: shmem in apr
Date Mon, 29 May 2000 14:44:33 GMT

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

> 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
somebody to implement shared memory across either un-related processes or
processes that use exec.  See the answer to the next section for more

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


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message