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, when I am loading the configuration file I have to allocate additional memory. This apparently doesn't get stored in the same shared memory as it isn't sticking around. How do I dynamically allocate new memory to the struct that lives in shared memory?
Jason On Mon, Jun 20, 2011 at 3:29 PM, Neil McKee <neil.mc...@inmon.com> wrote: > 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 you. > Source code is here: > > http://mod-sflow.googlecode.com > > Neil > > > On Jun 20, 2011, at 11:39 AM, 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 has it reloads the configuration. The configuration should be shared > over > > the entire server. The problem I am running into is that after the > > configuration file is updated the new configuration gets reloaded and > stored > > in memory but after a little while, the configuration reverts back to > it's > > previous version. 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...) > > > > My question is this: What mechanism should I be using in order to > > store persistent, mutable, configuration data that is shared between > every > > child process? > > > > > > Jason > >
