On Mon, Jun 20, 2011 at 22:46, Jason Funk <jasonlf...@gmail.com> 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 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?
Try C++ and boost::interprocess::managed_shared_memory and boost::interprocess::allocator. Sorin > > 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 >> >> >
