David Wortham wrote: > On 10/10/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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
