On Wed, 14 Nov 2001, Brian Pane wrote:
apr_mmap_dup() with an optimization for the ancestor-pool case sounds
good to me. Actually, with a slight modification, I think this can
handle the non-ancestor-pool case too:
* Create a reference count, in storage outside of any pool. (I have
On Sun, 4 Nov 2001, Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
whatever you do please remember to make sure you don't consume lots of
extra memory for the many tables which have only 1 or 2
dean gaudet wrote:
[...]
you can always have an elt array and then use some other method to index
into the elt array...
but that sucks :)
Agreed. What I've found so far is that it's difficult to actually
improve the speed of tables if you have to update both the elt
array and an additional index.
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/11/14 08:36:16 $]
Release:
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/07/13 03:51:20 $]
Release:
2.0a9 : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Need apu_compat.h to track the latest renames
Status: someone want to step up to diff
Okay, I found a patch that solves the problem for me. Cliff, please test and
let me know if it fixes your problem. I am also not sure that I like this
patch. But, I will post it here and let people comment.
Index: memory/unix/apr_pools.c
On Wed, 14 Nov 2001, Ryan Bloom wrote:
Okay, I found a patch that solves the problem for me. Cliff, please
test and let me know if it fixes your problem. I am also not sure
that I like this patch. But, I will post it here and let people
comment.
I'm running the tests on this. But doesn't
Based on Cliff's suggestion, this patch introduces an apr_mmap_dup()
function that's used to setaside mmap buckets without having to
memcpy the content.
I gave up trying to do full reference counting semantics for
duplicates of apr_mmap_t, because I couldn't find a suitable
pool to own the locks
On Wednesday 14 November 2001 09:52 pm, Cliff Woolley wrote:
On Wed, 14 Nov 2001, Ryan Bloom wrote:
Okay, I found a patch that solves the problem for me. Cliff, please
test and let me know if it fixes your problem. I am also not sure
that I like this patch. But, I will post it here and
On Wed, 14 Nov 2001, Ryan Bloom wrote:
I couldn't decide if it was bad mojo or not, which is why I didn't
just commit it. The structures will still be valid BTW, the only real
difference is that we run cleanups before we destroy memory.
Not exactly. Before, the subpools were being destroyed
On Wed, 14 Nov 2001, Brian Pane wrote:
I gave up trying to do full reference counting semantics for
duplicates of apr_mmap_t, because I couldn't find a suitable
pool to own the locks that would be required in a threaded
implementation. Instead, apr_mmap_dup() lets the caller
specify which
Cliff Woolley wrote:
[...]
The patch includes a change to mod_file_cache to create a non-owner
copy of the mmap for the bucket brigade to use, so that the mmap can't
get unmapped by any code other than mod_file_cache itself
Why is that necessary? The original mmap from mod_file_cache is owned by
12 matches
Mail list logo
