httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <sor...@gmail.com>
Subject Re: Module External Configuration
Date Mon, 20 Jun 2011 21:56:57 GMT
On Mon, Jun 20, 2011 at 22:46, Jason Funk <jasonlfunk@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.mckee@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
>>
>>
>

Mime
View raw message