Roy T. Fielding wrote:
Another reason why apr_hash_t isn't a good match for HTTP headers
is that the same field name may appear multiple times in the request
or response headers (section 4.2 of RFC 2616), but the hash table
implementation is designed around unique keys.
HTTP headers were designed
On Mon, Jul 09, 2001 at 04:50:31PM -0700, [EMAIL PROTECTED] wrote:
cool, huh? [and it's only 1024 LOC yes i know it's not
portable like APR i was v.impressed that someone actually
looked at it when i first mentioned it here, btw ]
so *grin*.
can you guarantee thread-safety on
Jon Travis wrote:
[...]
Tables should definitely be moved to APR-util if they are to remain. As
for Apache, there are better structures that dictate general order than
the table. IMNSHO, the only reason tables are still in Apache is inertia.
Nobody wants to go through and change everything to a
[Is it just me or is it nearly impossible to have a conversation about
Apache or APR that doesn't in some way belong on BOTH lists? sigh]
On Mon, 9 Jul 2001, Brian Pane wrote:
It's worth noting that half of the apr_table_get calls in
Apache are from mod_mime. I posted a patch to new-httpd
On Mon, Jul 09, 2001 at 08:14:26PM -0700, Jon Travis wrote:
Tables should definitely be moved to APR-util if they are to remain. As
for Apache, there are better structures that dictate general order than
the table. IMNSHO, the only reason tables are still in Apache is inertia.
Nobody wants
Justin Erenkrantz wrote:
On Mon, Jul 09, 2001 at 08:14:26PM -0700, Jon Travis wrote:
Tables should definitely be moved to APR-util if they are to remain. As
for Apache, there are better structures that dictate general order than
the table. IMNSHO, the only reason tables are still in Apache is
On Mon, 9 Jul 2001, Luke Kenneth Casson Leighton wrote:
HOWEVER! supporting the data types that apr_pool_xxx() USES
is a different matter.
shm can be at different memory locations in all processes. pointers don't
work. you'd need to radically change the basic data types, which would
affect
On Mon, 9 Jul 2001, Roy T. Fielding wrote:
Tables are in APR, because were originally moved from Apache to APR before
APR-util existed. They should really move to apr-util. They should never
be removed from Apache. Tables are useful because they garuantee a
general order to the data,
... errr.. should i be using apr_hash_t or something? :)
Yes.
okay. will take a look at it, to see where i could use it.
i have a suspicion that a lot of instances i really _need_
the case-insensitive stuff, and also need the dual
set and add capability.
not least because HTTP POST args
On Sun, Jul 08, 2001 at 10:19:33AM -0700, Justin Erenkrantz wrote:
On Sun, Jul 08, 2001 at 10:14:16AM -0700, dean gaudet wrote:
an ideal situation for free-lists (blocks of freed, but not free()d
memory) is one per cpu.
a less ideal situation is one per thread.
an even less ideal
On Tue, Jul 10, 2001 at 04:52:25PM +0200, Luke Kenneth Casson Leighton wrote:
... errr.. should i be using apr_hash_t or something? :)
Yes.
okay. will take a look at it, to see where i could use it.
i have a suspicion that a lot of instances i really _need_
the case-insensitive
Sander Striker wrote:
I'll think out loud now:
Me too :-)
The solution might be adding specific allocation functions for SMS
implementations. These functions could look something like this:
APR_DECLARE(void *) apr_sms_child_malloc(apr_sms_t *sms,
apr_sms_t
a nice connection)
david
- Original Message -
From: Brian Pane [EMAIL PROTECTED]
To: Sander Striker [EMAIL PROTECTED]
Cc: APR Development List dev@apr.apache.org
Sent: Monday, July 09, 2001 1:46 AM
Subject: Re: Observations on fragmentation in SMS pools
Sander Striker wrote:
I'll
To be honest changing sms_trivial to use malloc instead of
apr_sms_malloc is
an easy move (just a few lines to change) so it's probably worth
trying and then seeing what we get...
Massive leakage :)
Remember how the apr_sms_reset code works; it does not have to
traverse and destroy all
Sander Striker wrote:
To be honest changing sms_trivial to use malloc instead of
apr_sms_malloc is
an easy move (just a few lines to change) so it's probably worth
trying and then seeing what we get...
Massive leakage :)
Remember how the apr_sms_reset code works; it does not have to
traverse
regarding fragmentation:
is it reasonable to assume that pre-allocating larger chunks of
memory and sub-dividing them yourself will prevent memory
fragmentation, with the side-effect of having More Code?
use hash tables to optimise the list-walking?
write a better sms instance, one that isn't
On Sun, Jul 08, 2001 at 10:56:59AM -0700, Jon Travis wrote:
On Sun, Jul 08, 2001 at 10:41:12AM -0700, dean gaudet wrote:
On Sun, 8 Jul 2001, Jon Travis wrote:
There is still all this tomfoolery with locking, though, which I think
would be nice to fix with different sized buckets in
On Mon, Jul 09, 2001 at 05:49:24PM +0200, Luke Kenneth Casson Leighton wrote:
On Sun, Jul 08, 2001 at 11:06:33AM -0700, Justin Erenkrantz wrote:
On Sun, Jul 08, 2001 at 11:04:09AM -0700, Jon Travis wrote:
As for the ability to use shared memory for this ... yeah that is
an interesting
I added some instrumentation to apr_sms_trivial_malloc
to study in more detail where its bottlenecks were.
As a result, I found a few interesting phenomena:
1. The good news is that allocations of small amounts
of memory are very efficient. They almost always
take the fastest path through the
On Sun, Jul 08, 2001 at 12:47:32AM -0700, Brian Pane wrote:
I added some instrumentation to apr_sms_trivial_malloc
to study in more detail where its bottlenecks were.
As a result, I found a few interesting phenomena:
1. The good news is that allocations of small amounts
of memory are
Justin Erenkrantz wrote:
Aaron pointed out that CLR (Cormen/Leiserson/Rivest for those that never
took algorithms classes) has many memory allocation algorithms. I'd
bet we could find one that would work better. -- justin
At USENIX there was a talk about extending the slab allocator to
1. The good news is that allocations of small amounts
of memory are very efficient. They almost always
take the fastest path through the code, in which
some available space is reserved from the
sms-used_sentinel.prev block with a handful of
pointer arithmetic
1. The good news is that allocations of small amounts
of memory are very efficient. They almost always
take the fastest path through the code, in which
some available space is reserved from the
sms-used_sentinel.prev block with a handful of
pointer arithmetic operations.
I've been working on a power of 2 allocator. I still haven't got that up
to speed yet, but it is worth a look. I'll play with it this week and post
it to the list
I hacked a simple power of two allocator together as a proof of concept that
replacing
malloc/free with apr_malloc/apr_free
On Sun, 8 Jul 2001, Ian Holsman wrote:
Bill Stoddard wrote:
I've been working on a power of 2 allocator. I still haven't got that up
to speed yet, but it is worth a look. I'll play with it this week and post
it to the list
I hacked a simple power of two allocator together as a proof
On Sun, 8 Jul 2001, Ian Holsman wrote:
I was wondering why the brigade code doesn't make use of pools/sms to
handle it's memory.
It has a pool passed to it from what I can see...
The brigade is allocated out of a pool, and that pool is used to register
a cleanup on the brigade to make sure
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Yup. I've brought this up to Sander and David before, but this is how
pools
woah. no way really?
that's not at all how it was in 1.3 or in early 2.0 ...
in 2.0 as of uh a year ago say, there was one free list per process,
and locks were used
On Sun, Jul 08, 2001 at 10:14:16AM -0700, dean gaudet wrote:
an ideal situation for free-lists (blocks of freed, but not free()d
memory) is one per cpu.
a less ideal situation is one per thread.
an even less ideal situation is one per process (which requires locking).
it's insane to
On Sun, Jul 08, 2001 at 10:18:12AM -0700, dean gaudet wrote:
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Yup. I've brought this up to Sander and David before, but this is how
pools
woah. no way really?
that's not at all how it was in 1.3 or in early 2.0 ...
in 2.0 as of uh a
On Sun, Jul 08, 2001 at 10:34:22AM -0700, Jon Travis wrote:
There is still all this tomfoolery with locking, though, which I think
would be nice to fix with different sized buckets in the freelist.
Stuff that the malloc in glibc does. I cringe at the thought of how
much overhead due to
Stuff that the malloc in glibc does. I cringe at the thought of how
much overhead due to abstraction this whole project is causing.
The other thing this abstraction buys us is the ability to pass in
different memory to standard APR operations. Hopefully we can get
shared memory to work in this
On Sun, Jul 08, 2001 at 10:41:12AM -0700, dean gaudet wrote:
also -- it would be worthwhile for someone to try a version of pools which
keeps no freelist, and uses malloc()/free() on each block. i'm guessing
this is faster in a multithreaded server than us doing a per-process
global list
On Sun, Jul 08, 2001 at 11:04:09AM -0700, Jon Travis wrote:
As for the ability to use shared memory for this ... yeah that is
an interesting idea. What are your actual use cases for that?
Ian posted a patch to do something like this - I think he wanted a hash
table that was shared across all
On Sun, 8 Jul 2001, Jon Travis wrote:
I talked to rbb about this not too long ago, and he told me that you
did a lot of performance work, and that is why pools use their own
allocation scheme (8k blocks, freelists, etc.) instead of using a
total malloc() oriented scheme.
yes and no. i can't
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Also, I did try having the pools use malloc/free directly
(ALLOC_USE_MALLOC) and the performance was dreadful. At least on
Solaris. -- justin
yes, ALLOC_USE_MALLOC is dreadful -- that's not what i meant.
what i mean is something like the below
dean gaudet wrote:
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Also, I did try having the pools use malloc/free directly
(ALLOC_USE_MALLOC) and the performance was dreadful. At least on
Solaris. -- justin
yes, ALLOC_USE_MALLOC is dreadful -- that's not what i meant.
what i mean is something
On Sun, 8 Jul 2001, Ian Holsman wrote:
dean gaudet wrote:
it removes block_freelist and uses malloc/free for blocks. this is much
less expensive than malloc/free on each allocation (amortization).
If you can wait till monday, and you are interested, I'll put it through
the ringer on a
On Sun, 8 Jul 2001, Brian Pane wrote:
dean gaudet wrote:
On Sun, 8 Jul 2001, Ian Holsman wrote:
dean gaudet wrote:
it removes block_freelist and uses malloc/free for blocks. this is much
less expensive than malloc/free on each allocation (amortization).
If you can wait till monday,
Jon Travis wrote:
On Sun, Jul 08, 2001 at 11:27:08AM -0700, Ian Holsman wrote:
Justin Erenkrantz wrote:
On Sun, Jul 08, 2001 at 11:04:09AM -0700, Jon Travis wrote:
[snip]
I'm still curious about the use case. I'm sure there is one, if you
could just enlighten me. I already know it's 'cool'.
for
dean gaudet wrote:
On Sun, 8 Jul 2001, Ben Laurie wrote:
Justin Erenkrantz wrote:
Aaron pointed out that CLR (Cormen/Leiserson/Rivest for those that never
took algorithms classes) has many memory allocation algorithms. I'd
bet we could find one that would work better. -- justin
40 matches
Mail list logo
