On Mon, 20 Jun 2011 16:10:12 -0400
Mike Meyer wrote:
> I assume that this is because a new process was spawned to
> > handle a new request and the updated memory didn't get carried over (even
> > though the pointer address didn't change...)
A new process may be spawned from time to time (thou
On Mon, Jun 20, 2011 at 22:46, Jason Funk wrote:
> I have moved my configuration over to shared memory (following
> mod_shm_counter as an example) and it conceptually seems to be working. I am
> storing a struct in the memory and members that share it's memory (such as
> the last mod time of the c
On Mon, Jun 20, 2011 at 22:46, Jason Funk wrote:
> I have moved my configuration over to shared memory (following
> mod_shm_counter as an example) and it conceptually seems to be working. I am
> storing a struct in the memory and members that share it's memory (such as
> the last mod time of the c
I have moved my configuration over to shared memory (following
mod_shm_counter as an example) and it conceptually seems to be working. I am
storing a struct in the memory and members that share it's memory (such as
the last mod time of the configuration file) persist over multiple children.
However
In the mod-sflow implementation I have one thread responsible for reading in
new configuration as it changes and writing it to a shared-memory area where
the worker-processes/threads can pick it up whenever it changes. I don't know
if that is the best way or not, but it's one data point for y
On Mon, 20 Jun 2011 13:39:48 -0500
Jason Funk wrote:
> Hello,
>
> The module that I am writing has an external configuration file that it
> parses and loads into configuration when the server loads. Before every
> request it checks to see if the configuration file has been updated and if
> it ha
