It is. Please commit the change. We should not be regularly holding up
developers just to get a good build. When the server is stable,
sombody/anybody should tag and roll a new version. If the tree isn't
stable, we don't tag/roll. We should only be holding up developers if we
are absolutely
[EMAIL PROTECTED] wrote:
It is. Please commit the change. We should not be regularly holding up
developers just to get a good build. When the server is stable,
sombody/anybody should tag and roll a new version. If the tree isn't
stable, we don't tag/roll. We should only be holding up
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
Hi,
It would be usefull to add stats to the sms code. David has
a patch for that, so I'm sure that will go in.
Now, based on that I'm thinking of doing something more
sophisticated with the data than just dumping it on screen
or in a file. I want to collect all the stats data,
group it by
Well, you could read it differently. Look at images
233 to 259, then look at 260. Now why are all those
destroyed individually, when one destroy, the one in
260 could take care of them all?
Did these all result from calls to ap_destroy_sub_req?
Could very well be. Guess that showing
When one of us gets a chance, we can implement the child_malloc path in
trivial. That should remove most of the current complaints about SMS.
so, you want to add apr_sms_child_malloc etc. which makes
SMS a non-trivial API, which is one solution to the problem,
and the other solution is
On Tue, Jul 10, 2001 at 11:45:01AM -0700, Brian Pane wrote:
Sander Striker wrote:
Cliff pointed out to me that using my homedir for this stuff might be
a better idea (instead of people pounding my ADSL).
I saw some hits on my box and think that people were scared away by
the size of the
On Wed, Jul 11, 2001 at 04:32:54PM +0200, Sander Striker wrote:
When one of us gets a chance, we can implement the child_malloc path in
trivial. That should remove most of the current complaints about SMS.
so, you want to add apr_sms_child_malloc etc. which makes
SMS a non-trivial
On Wed, Jul 11, 2001 at 07:43:14AM -0700, [EMAIL PROTECTED] wrote:
APR doesn't really handle signals, for a very good reason. They are
incredibly non-portable, and very difficult to deal with. Having said
that, there are some APR functions for dealing with signals.
1) apr_signal. Just
also, would someone like to write an apr_sms_trivial_using_hashchains?
the idea here would be that the size of the memory block
is used as a hash-lookup into the currently-available free chain,
instead of list-walking.
surely, that saves time, yes?
anyone care to refute this hypothesis
On Wed, Jul 11, 2001 at 04:53:54PM +0200, Luke Kenneth Casson Leighton wrote:
how are you going to keep _users_ from _not_ using apr_sms_child_xxx
and friends?
It's not exported as a function? Only a SMS itself would see this
function?
not being funny or anything, but what is a trivial
could someone explain to me why there are two stacks
of apr_sms_trivial, such that you get the double
list-walk in the first place?
please? :)
Ok, this is due to the way we have created the patch to
allow sms to be used instead of pools. We chose the
trivial sms as the replacement for _all_
The exported API to userland will not change (see below).
ack. okay. makes me happier.
i know that there have been message flying back/forth.
i don't understand them.
please do me a favour: could you write up a clear explanation
of exactly what the purpose of apr_sms_child_malloc
[EMAIL PROTECTED] wrote:
dreid 01/07/11 07:20:31
Modified:.configure.in
memory/unix apr_sms.c sms_private.h
include apr_pools.h apr_sms.h
Whoops! seems to have broken the build:
/bin/sh /home/gregames/apache/httpd-2.0/srclib/apr/libtool
if you use malloc/free directly (for blocks, not for each palloc) and have
no free list then on linux the ptmalloc built into libc will do per-cpu
free listing for you. similarly on solaris with the shipped mtmalloc
library. and on either of those platforms with the hoard library.
[...]
so
At 01:01 PM 07/11/2001, dean gaudet wrote:
i know nothing about the quality of windows malloc on multi-cpu boxes.
As of VC++ 6.0 SP4:
There is a small block freelist for blocks 0x3F8 or smaller. It uses
a critical section around the allocator. Anything larger falls
through to the HeapAlloc
On Wed, Jul 11, 2001 at 12:01:50AM +0200, Sander Striker wrote:
I want to discuss this some more to be honest. There
are several options we can try and I feel it is best
to examine more than one, even though one looks like
the way to go. A per-CPU free list will be difficult
to implement
However, my question, and point, can't we do without
destroying all the subreqs individualy and just destroy
the request?
No can do... it's very easy to come up with a request that causes many
thousands of subrequests to be made (think mod_autoindex on a big
directory). If you don't
I committed the proper fix to this a few hours ago
(SMS_ALLOC_STATS-APR_SMS_ALLOC_STATS).
The sluggish list isn't helping things much. -- justin
On Wed, Jul 11, 2001 at 02:04:38PM -0400, Greg Ames wrote:
[EMAIL PROTECTED] wrote:
dreid 01/07/11 07:20:31
Modified:.
19 matches
Mail list logo
