Question about APR SHM

[Alex Wulms <al...@scarlet.be>]

Hi,

I have got a question about APR SHM. The comments of the function
apr_shm_baseaddr_get(const apr_shm_t *m) indicate that the resulting
address is only valid in the callers address space, since the API does
not guarantee that other attaching processes will maintain the same
address mapping.

When I look at the implementation of modules that use SHM (like mod_ssl
and mod_ldap), it seems like the address returned by the function is
re-used as-is in the worker child processes. In both modules, the above
function is invoked from the post_config handler and the resulting
memory structure is then used in the worker child processes.

So my question is: when is the note about the validity of the resulting
address applicable? Is it only applicable when a new process has
attached itself explicitly to an already existing SHM segment with the
apr_shm_attach(...) function? And can I safely ignore it when it
concerns an implicit attachment (inherited) by the child process? And is
it like that on all supported platforms and not only on Unix (I know for
a fact that it is indeed like this on Unix)?

Thanks and kind regards,
Alex

 

Re: Question about APR SHM

[Alex Wulms <al...@scarlet.be>]

Op 31-07-10 18:07, Alex Wulms schreef:
> Hi,
>
> I have got a question about APR SHM. The comments of the function
> apr_shm_baseaddr_get(const apr_shm_t *m) indicate that the resulting
> address is only valid in the callers address space, since the API does
> not guarantee that other attaching processes will maintain the same
> address mapping.
> ...
>   
Hi,

In order to play it safe, I have made my code function completely on top
of the RMM  (relocatable memory management) API already present in APR.

As a side-product, I have written a re-usable RMM hash table (derived
from apr_hash.c). You can find the code in the GIT repository located here:
http://repo.or.cz/w/httpd-crcsyncproxy.git

It concerns files crccache/rmm_hash.h and crccache/rmm_hash.c in the
repository.

Please feel free to include them in a future version of APR.

Kind regards,
Alex