Having it separated out like you have just changed it to is going
to cause lots of problems for us maintaining it. While your
As to wether this is realistic: From apache-1.3/src/support/ab.c:
#define VERSION 1.3d
which has been there for some XXX years and allowed us to compare
ab
I think maybe we should move ab out of the tree in this case...
david
Having it separated out like you have just changed it to is going
to cause lots of problems for us maintaining it. While your
As to wether this is realistic: From apache-1.3/src/support/ab.c:
#define VERSION 1.3d
Maybe we should have atomics disabled by default, at least right
now... with the build problems on some Linuxes and the Solaris
compatibility stuff, it's been snagging us. I don't want it to
delay 2.0.36 if possible.
--
===
Paul has been doing some testing and this patch seems to help (but not solve) the
reported
problem. The idea behind the patch is to start as many worker threads as possible on
the
first pass through the for() loop before starting the listener. Starting the listener
earlier on a loaded server
1) $prefix isn't getting fixed-up by install-bindist.sh, at least on
Solaris
2) where is the build directory? we need some stuff like
config_vars.mk
3) a cool problem you'll run into after fixing the above
download a binary build
install it
run apxs
ouch!
apxs doesn't pick up the
I like the idea of statically linking apr/apr-util to httpd. Just not sure how that
impacts DSOs that need APR functions.
How 'bout creating a script in bin, setupenvars.bat than folks need to learn to run
before
issuing httpd -yadda? Not pretty but very straight forward...
Bill
-
Bill Stoddard [EMAIL PROTECTED] writes:
(I would have quoted but the text is way out at columns 89-92 or so)
I think the patch is fine, but I can't help but suspect that some of
the pain you are alleviating is caused by the known problem where the
listener thread can accept connections when
Jim Jagielski [EMAIL PROTECTED] writes:
Maybe we should have atomics disabled by default, at least right
now... with the build problems on some Linuxes and the Solaris
compatibility stuff, it's been snagging us. I don't want it to
delay 2.0.36 if possible.
I could go for that or for a
+* The worker MPM should not accept more connections than it
+ currently has available workers. Instead, the listener thread
+ should block on a condition of the fdqueue such that it waits
+ until there are at least one idle worker before continuing
+ into
Jeff,
In my tests, this patch allows existing worker threads to continue
procesing requests while the new threads are started.
In the previous code the server would pause while new threads were
being created. The new threads started accepting work immediately,
causing the existing threads to
+* The worker MPM should not accept more connections than it
+ currently has available workers. Instead, the listener thread
+ should block on a condition of the fdqueue such that it waits
+ until there are at least one idle worker before continuing
+
On Fri, Apr 26, 2002 at 11:32:19AM -0400, Paul J. Reder wrote:
In my tests, this patch allows existing worker threads to continue
procesing requests while the new threads are started.
In the previous code the server would pause while new threads were
being created. The new threads started
On 26 Apr 2002, Jeff Trawick wrote:
I could go for that or for a --disable-atomic switch which could be
used to alleviate any problems if they happen.
+1 to either option. Enabled by default is probably okay since it will
help us track down problems, so I'll lean toward --disable-atomic.
On Fri, Apr 26, 2002 at 11:32:19AM -0400, Paul J. Reder wrote:
In my tests, this patch allows existing worker threads to continue
procesing requests while the new threads are started.
In the previous code the server would pause while new threads were
being created. The new threads
As per a previous email, I was going to create a new MPM that had a
dispatcher sitting between the listener and the workers that would handle
all of the queueing problems via signaling. I will have to defer that
project at present due to workload at my job. However, in the current
discussion on
Aaron Bannert [EMAIL PROTECTED] writes:
+1 to either option. Enabled by default is probably okay since it will
help us track down problems, so I'll lean toward --disable-atomic.
Although I'd really like to see the atomics code work, having to
specify --please-make-my-binaries-portable
Bill Stoddard wrote:
+* The worker MPM should not accept more connections than it
+ currently has available workers. Instead, the listener thread
+ should block on a condition of the fdqueue such that it waits
+ until there are at least one idle worker before
Although I'd really like to see the atomics code work, having to
specify --please-make-my-binaries-portable is not good enough for me. :(
Optimizations that narrow the scope of portability must be optional.
I thought this thread was in regards to the compile issues that
various folks
On 26 Apr 2002 [EMAIL PROTECTED] wrote:
+
+* The atomics code produces binaries that are not forward compatible
+ on Solaris (eg. Solaris 5.6 binaries can fail on older hardware
+ running on Solaris 7). (See APR's STATUS file.)
I don't see what the big deal is. The
On Fri, 26 Apr 2002, Bill Stoddard wrote:
+ * later
+ */
+if (!worker_thread_cnt) {
+yield();
+continue;
+}
+
It compiles, but it doesn't link. No such thing as yield():
server/mpm/worker/.libs/libworker.al(worker.lo): In function
On Fri, 26 Apr 2002, Bill Stoddard wrote:
This is a patch to worker.c to prevent more connections from being
accepted than there are workers to handle them. The accept thread
decrements the avail count and the workers increment the avail count. I
don't have a linux box handy so i cannot
On Fri, Apr 26, 2002 at 02:07:29PM -0400, Bill Stoddard wrote:
This is a patch to worker.c to prevent more connections from being accepted than
there are
workers to handle them. The accept thread decrements the avail count and the workers
increment the avail count.
How about using APR
On Fri, 26 Apr 2002, Justin Erenkrantz wrote:
Besides, isn't there a race condition here? Or are you assuming ++ and --
are atomic?
IIRC, there's no guarantee for that. -- justin
Right. That's why I'm confused. :)
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am close to completing a port of mod_auth_external to Apache 2.0 API.
I have attempted to reach the authors with no success. Do you have an
updated list of who I should send my patches to?
Regards,
Dave Lambert.
- --
David Lambert
Director of
On Fri, Apr 26, 2002 at 11:18:58AM -0700, Justin Erenkrantz wrote:
How about using APR condition variables instead of yield()? That was
how I was imagining implementing this. The listener would block
until the queue is not full and then drop into the accept mutex
rotation. I seem to
On Fri, 26 Apr 2002, Aaron Bannert wrote:
LIFO-FIFO change this morning and added a counter to keep track of the
number of elements in the queue. That can be used in a new function
that blocks until the queue is non-full.
You mean non-empty, I presume.
--Cliff
On Fri, Apr 26, 2002 at 02:53:59PM -0400, Cliff Woolley wrote:
On Fri, 26 Apr 2002, Aaron Bannert wrote:
LIFO-FIFO change this morning and added a counter to keep track of the
number of elements in the queue. That can be used in a new function
that blocks until the queue is non-full.
On Fri, 26 Apr 2002, Bill Stoddard wrote:
This is a patch to worker.c to prevent more connections from being
accepted than there are workers to handle them. The accept thread
decrements the avail count and the workers increment the avail count. I
don't have a linux box handy so i
Jeff Trawick [EMAIL PROTECTED] writes:
1) $prefix isn't getting fixed-up by install-bindist.sh, at least on
Solaris
now fixed
2) where is the build directory? we need some stuff like
config_vars.mk
now fixed
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an
Bill Stoddard wrote:
On Fri, 26 Apr 2002, Bill Stoddard wrote:
This is a patch to worker.c to prevent more connections from being
accepted than there are workers to handle them. The accept thread
decrements the avail count and the workers increment the avail count. I
don't have a linux box
Jeff Trawick [EMAIL PROTECTED] writes:
3) a cool problem you'll run into after fixing the above
download a binary build
install it
run apxs
ouch!
apxs doesn't pick up the environment variable needed to find libapr,
libaprutil, libexpat, so httpd -l bombs...
This doesn't seem to hurt
At 12:24 PM -0400 4/26/02, Jeff Trawick wrote:
Aaron Bannert [EMAIL PROTECTED] writes:
+1 to either option. Enabled by default is probably okay since it will
help us track down problems, so I'll lean toward --disable-atomic.
Although I'd really like to see the atomics code work, having to
David Lambert [EMAIL PROTECTED] writes:
I am close to completing a port of mod_auth_external to Apache 2.0 API.
I have attempted to reach the authors with no success. Do you have an
updated list of who I should send my patches to?
That module isn't maintained by the ASF. You could always
On Fri, 26 Apr 2002, Thomas Eibner wrote:
After a short discussion on #apache we came to the conclusion that the
way mod_auth_anon logs the passwd used to access the uri is kind of
annoying. So instead of logging to the error log we decided it might
be smart if it used the ident field.
On Fri, Apr 26, 2002 at 12:49:12PM -0700, Joshua Slive wrote:
On Fri, 26 Apr 2002, Thomas Eibner wrote:
After a short discussion on #apache we came to the conclusion that the
way mod_auth_anon logs the passwd used to access the uri is kind of
annoying. So instead of logging to the
On Fri, 26 Apr 2002, Thomas Eibner wrote:
After a short discussion on #apache we came to the conclusion that the
way mod_auth_anon logs the passwd used to access the uri is kind of
annoying. So instead of logging to the error log we decided it might
be smart if it used the ident field.
On Fri, 26 Apr 2002, Joshua Slive wrote:
On Fri, 26 Apr 2002, Thomas Eibner wrote:
After a short discussion on #apache we came to the conclusion that the
way mod_auth_anon logs the passwd used to access the uri is kind of
annoying. So instead of logging to the error log we decided it
On Fri, 26 Apr 2002, Rich Bowen wrote:
annoying. So instead of logging to the error log we decided it might
be smart if it used the ident field.
Ehhh... too much overloading. Why not stick it in the environment
and then use %{something}e to log it?
I don't really see this as
I don't understand why you didn't simply reverse the test and
enclose the frequent case inside the if {} block. I assume it
was just to avoid indenting a large block of code, which is not
sufficient justification for a goto.
A goto often has unforeseen effects on high-level optimizations
that
On Thursday, April 25, 2002, at 03:27 PM, Justin Erenkrantz wrote:
On Thu, Apr 25, 2002 at 04:39:18PM -0400, Bill Stoddard wrote:
From http_protocol.c...
* 1. Call setup_client_block() near the beginning of the request
*handler. This will set up all the necessary properties, and will
We need to sync httpd-2.0's repository up with all the latest changes in
mod_ssl 2.8.8. Our last sync-up was at mod_ssl version 2.8.7, so it
shouldn't be that big a patch. I'll do that tonight, but preferably those
changes would be included in 2.0.36... at Sander's discretion, of course.
On Fri, Apr 26, 2002 at 06:56:33PM -0700, Justin Erenkrantz wrote:
+rv = ap_queue_info_wait_for_idler(worker_queue_info);
+if (APR_STATUS_IS_EOF(rv)) {
+break; /* we've been signaled to die now */
+}
+else if (rv != APR_SUCCESS) {
+
From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
Sent: 27 April 2002 04:17
+qi = apr_palloc(pool, sizeof(*qi));
+memset(qi, 0, sizeof(*qi));
Why not apr_pcalloc?
I've made a habit of not using calloc. palloc+memset is faster.
Huh? apr_pcalloc == apr_palloc + memset. The
On Fri, Apr 26, 2002 at 10:30:53PM -0400, Cliff Woolley wrote:
No, there's another difference: many optimizers will see the memset call
and that it has a constant size as its argument and will replace that call
(which is fairly expensive due to a loop and so fort) with inline code to
zero out
44 matches
Mail list logo
