On Mon, 20 Jun 2011 16:10:12 -0400 Mike Meyer <m...@mired.org> 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 (though not directly to handle a new request unless you have a very non-standard MPM). You could check config data in a child_init hook. However, if you have this problem, it's probably not your only one. The data reverting suggests that your module's config may be held on the server/config pool. If that's being updated (and if the updates involve any allocation at all) it's a memory leak. Your module should create its own config pool at child_init. Then it can read its own config data immediately, and - crucially - whenever it re-reads the data it can first clean that pool to reclaim memory. > Put the configuration data into shared memory. Create and load the > shared memory in the post config hook. Map the shared memory and > potentially reload it during the child init hook. You'll need to use > appropriate locking if you decide to reload it. Details on the locking > will depend on the data structure details. If you use shared memory, note that 2.3/2.4 have much better support for it than earlier versions, with mod_socache and mod_slotmem. However, this may not be the best thing to do. You need to weigh up the cost of maintaining a per-process copy of the config data against that of using shared memory. Both are valid solutions. Also, do you want the overhead of a stat() every request to see if anything has changed, or could it work on a time basis, so it only performs a stat() if a certain time has elapsed since the last time? -- Nick Kew Available for work, contract or permanent. http://www.webthing.com/~nick/cv.html
