Sander Striker wrote:
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
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/06/29 08:00:48 $]
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
The pattern in your graphs (lots of subpool destructions in a row)
was strange. It looks like a lot of subrequests didn't get destroyed
until the parent request was about to go out of scope. This looks like
a bug. What type of request was it? (Directory index, maybe?)
It was a request of
that Does A Better Job, well... tough! go use or write
something else that isn't trivial'.
Ah, the naming issue :)
I raised that a couple of times before commiting, and noone as
of yet has come up with a better name. I started out writing
apr_sms_...
trivial_buffered
On Wed, Jul 11, 2001 at 09:08:47AM -0700, Aaron Bannert wrote:
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.
On Wed, Jul 11, 2001 at 08:14:15AM -0700, [EMAIL PROTECTED] wrote:
okay... so... what you are saying, effectively, is that apache is
vulnerable to a SIGPIPE DOS attack, amongst others.
It shouldn't be. We block all signals in all processes, and only listen
for those we care about.
okay!
On Thu, Jul 12, 2001 at 11:20:59AM +0200, Sander Striker wrote:
[...]
we _know_ that malloc and free are pretty efficient on
most operating systems. so why not rely on that
efficiency instead of trying to second-guess it and
round-up the malloc-block sizes?
Because we most
Realistically, though my thought for the long term is to have one root
trivial SMS (or similar SMS with a freelist) per thread
and a bunch of
tracking SMS (brain-dumb five-minute SMS that don't do much). I really
think this is where we ought to be headed. Does that need the
[...]
Here's a possible taxonomy of allocation types:
Type 1: Allocations that will not be returned to the SMS (and will
get freed only when the SMS itself is destroyed)
Type 2: Allocations that will be returned to the SMS during its
lifetime
And this can be accomplished
[...]
what i suspect is happening in subversion [correct me if i'm
wrong, here!] is that they are writing their own server-code.
You're wrong :)
subversion is going to use httpd with mod_dav as the server :)
Check out http://subversion.tigris.org/servlets/ProjectDocumentList
and
On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote:
[...]
what i suspect is happening in subversion [correct me if i'm
wrong, here!] is that they are writing their own server-code.
You're wrong :)
wha-heeey :) i like being wrong :)
subversion is going to use httpd with
On Thu, Jul 12, 2001 at 11:12:15AM +0200, Luke Kenneth Casson Leighton wrote:
one: pools in threads are messed up.
Yes.
two: sms can't be developed effectively because no changes are
allowed to existing code. and some of the solutions being proposed
involve pools and threads.
well,
On Thu, Jul 12, 2001 at 04:11:25PM +0200, Sander Striker wrote:
PS. I want to commit apr_threads_sms, but I don't know how to build
it conditionally. I could ofcourse just put #if APR_HAS_THREADS
#endif around all the code in apr_sms_threads.c, but that somehow
rubs me the wrong
Greg Marr wrote:
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
14 matches
Mail list logo
