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: Shared memory
Date Thu, 23 Nov 2006 15:34:44 GMT
Christiaan Lamprecht wrote:
> On 11/22/06, Brian McQueen <mcqueenorama@gmail.com> wrote:
>> In an old thread dated October 9, with the subject "server config
>> apr_table_t" there was some talk about this issue and it was mantioned
>> that the server config structure is to be considered non-volatile.
>> Did I get that right?
> 
>>> On 10/10/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>> 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.
> 
> Currently I'm using the server config but allocating my own memory
> (i.e. non-APR) So this should work? Albeit potentially playing with
> fire.

That's bad (non-APR memory) only when it isn't cleaned up and your module
doesn't withstand long-term operation.  The safest is to allocate a sub
pool from the request pool for per-request allocations, of a subpool from
the connection pool for socket-lifetime operations.

These are discarded (with your data) on recycle.

Mime
View raw message