httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: server config apr_table_t
Date Wed, 11 Oct 2006 03:16:05 GMT
David Wortham wrote:
> On 10/10/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>> You are responsible for mutexing; and remember unless you alloc before
>> fork and never modify the data, it's per-process private.
> 
> Is this to say that using a subpool of a "s->process->pool" pool, what
> mutations made by one child process won't be seen by other child
> processes?

All of them.  Understand that all malloc()ed memory heap pages in most
kernels are shared but marked copy-on-write.  As soon as any forked
process (every httpd child worker process) touches one byte in those
pages, they get their own copy of the memory that's then modified.

If you never write to pconf, then all child processes will continue to
share the same, single copy.  Until one writes to it, potentially
chewing up alot of memory if there are many processes and many small
changes in that pool.  That's why I say touching the global pools
such as pconf is just a bad idea.

So if you can't share palloc()'ed memory - what to do?  Use the apr_shm
or apr_mmap interfaces to create shared memory segments across processes.

> Right now, I have a module (based roughly off of mod_evasive 2.0 for
> website RBLing and caching of recent RBL lookups).  I'm using a file
> for caching, but I would like to have my lookups stored in
> parent-process memory so that each child process does not have to sync
> to the file and keep its own lookup hashtable.

gotcha

> BTW - I'm new to the mailiing list.  If I need to reformat or send
> replies in some other manner, please inform me.

Looks fine here

Mime
View raw message