--
Reply-To: new-httpd@apache.org
Date: Sun, 7 Jan 2001 11:51:47 -0800 (PST)
From: dean gaudet [EMAIL PROTECTED]
To: new-httpd@apache.org
Subject: woah, GET / with autoindex
X-comment: visit http://arctic.org/~dean/legal for information regarding
copyright and disclaimer.
woah. ok
On Sun, 7 Jan 2001, David Reid wrote:
Greg,
Nicely put and that's exactly what I had in mind but after spending 10 hours
flogging to St Pete back my mind isn't working as well as normal! (Mind
due, does it ever??) Of course I was going to use the TCP_ flags but the
APR should do the
i'm a bit of an I18N novice, but doesn't it all just magically work if you
use UTF-8 encoding everywhere?
UTF-8 deliberately avoids using \0 and / in the encodings. plain ascii
works unmodified. unix filesystems generally support UTF-8 directly
(because of the \0 and / avoidance).
this allows
i dunno, i think you either don't understand ap_pool_join, or something is
totally fucked up with it in 2.0. i wouldn't be surprised if it's that
2.0's POOL_DEBUG code is broken... go look at 1.3 and see if it makes more
sense.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
p.s.
On Wed, 9 May 2001, Luke Kenneth Casson Leighton wrote:
my point is that if you _don't_ #define POOL_DEBUG, this _isn't_ a
problem???
nope -- the ap_pool_join() is a promise by the caller that they won't
destroy pool B prior to destroying pool A. well, if you think of this in
terms of 1.3,
On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote:
what i perhaps should recommend is that a series of independent
libraries be created.
e.g. libaprhttputil (i know it's a bit long).
why?
we don't link against libcstdio libcstring libcsyscalls libcsortnsearch
...
the point of a
hi!
why aren't basic bit manipulations being done directly? the function call
overhead is enormous compared to the operations being performed.
also... when i saw the field named netmask i kind of assumed it was a
network address mask, which is usually what netmask refers to. why does
it appear
On Wed, 4 Jul 2001 [EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2001, Ian Holsman wrote:
I'm looking at the shared memory functions (in unix), and am struggling
to find out how one can attach to
a shared memory segment already created by another process.
Currently you can't, because MM
On Sat, 7 Jul 2001, Aaron Bannert wrote:
I don't think there is any benefit to this. But, someone else might
be able to chime in and say why we need this functionality. -- justin
how do you handle out of memory?
palloc is not permitted to return NULL for performance reasons.
On Mon, 2 Jul 2001, Brian Pane wrote:
On Mon, 2 Jul 2001, Brian Pane wrote:
then it should be possible to eliminate a system call by not doing the
initial read before the select.
Here's a patch that disables the read before the select, but only for
the HTTP client socket.
hey brian, i
On Sat, 7 Jul 2001, Brian Pane wrote:
If I'm reading the code right, there's one problem with this approach: the
APR_INCOMPLETE_READ flag doesn't get set until after the first
read on a socket, so the first read on a new connection (the one that
usually
returns EAGAIN) doesn't get skipped
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, 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
so while hacking up that patch to eliminate the block_freelist i thought i
could also get rid of the alloc_mutex entirely. but it appears that
currently the pool code sort of supports multithreaded access to the same
pool.
i say sort of because cleanups don't support multithreaded access -- no
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 8
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
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,
On 9 Jul 2001, Ian Holsman wrote:
maybe there needs to be a method of registering error numbers/functions
so that apr_sterror knows that error 1230981 is from apr-util and would
call apr-util's function it registered to show the error message.
hee!
sorry, just thinking back to discussions
On Sat, 14 Jul 2001, Aaron Bannert wrote:
On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make the dynamic locking a lot easier to implement if it stays.
all threads MUST have their own private
On Tue, 17 Jul 2001, Luke Kenneth Casson Leighton wrote:
therefore, i conclude that the dce/rpc codebase has successfully
implemented thread cancellation in their POSIX/Draft4 thread
library.
yes cancellation is in the spec. i've never denied that. the problem is
libraries and code over
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
And, from what I can tell, Dean Gaudet has mentioned this morning that
he is willing to veto async notification. Dean, would that include
cancellation of threads? I have a suspicion it might. Dean has
commit access on httpd as well, so if you
implementations of this mechanism will leak resources (aparently in the
kernel), and that is bad.
-aaron
On Tue, Jul 17, 2001 at 01:32:52AM -0700, dean gaudet wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level div instruction is a two result opcode, quotient and
remainder. if
On Tue, 17 Jul 2001, Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually
On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
We agree. APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual
case) value.
my complaint is that you're modifying all the handle creation APIs with
another parameter...
-dean
+1 from me too (although i don't know that i necessarily have a vote in
APR :)
-dean
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn,
rather assuming
On Tue, 17 Jul 2001, Brian Pane wrote:
dean gaudet wrote:
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level
On Mon, 23 Jul 2001, Aaron Bannert wrote:
Just on a side note, I also tried to reproduce this bug with my non-SMP
rh71 (linux 2.4.3) machine, and could not.
redhat 7.1's 2.4.3 includes a lot of the patches that eventually made it
into kernels as recent as 2.4.6. this is pretty typical of
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
On Sun, 18 Nov 2001, Brian Pane wrote:
Good point--it's possible to construct an O(n^2) attack with this
patch. The same is true of qsort, which is O(n^2) in the worst
case, but it's admittedly a lot harder to construct the worst-case
data set with qsort.
hmm yeah i guess that's true.
The
and trying to get a single block
to handle many common requests ...
On a thought from Dean Gaudet, how would performance be helped if
we #define'd apr_pcalloc to be:
#define apr_pcalloc(pool, size) memset(apr_palloc(pool, size), '\0', size);
When out of mem, this will segfault at the point where
i'd like to port mod_iptos to 2.x http://arctic.org/~dean/mod_iptos/...
and i need apr_socket_opt_set support for IP_TOS. so here's a patch.
sorry it's against 1.2.7 but that's what debian is still using. i'm sure
there'll be feedback and i'll rebase against whatever you want after
feedback.
35 matches
Mail list logo
