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
On Sat, 27 Apr 2002, Sander Striker wrote:
> Huh? apr_pcalloc == apr_palloc + memset. The only extra overhead
> is the extra function call
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
On Sat, Apr 27, 2002 at 04:33:25AM +0200, Sander Striker wrote:
> > I've made a habit of not using calloc. palloc+memset is faster.
>
> Huh? apr_pcalloc == apr_palloc + memset. The only extra overhead
> is the extra function call, since I was asked to reduce code dup
> and call apr_palloc from
> 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 +
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) {
> >
> 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
On Fri, Apr 26, 2002 at 05:07:29PM -0700, Aaron Bannert wrote:
Comments inline.
> Index: server/mpm/worker/worker.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
> retrieving revision 1.117
> diff -u -u -r1.117
In this patch I've added a new structure fd_queue_info_t that is a simple
counter, a mutex, and a condition variable. Only the listener thread
blocks on the condition, and only when there are no idle workers. In
the fast path there is a mutex lock, integer decrement, and and unlock
(among a few co
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.
Thank
On Fri, Apr 26, 2002 at 01:35:48PM -0400, Cliff Woolley wrote:
> I don't see what the big deal is. The compiler produces code that is just
> as incompatible [assuming we got the configure checks right in APR]. For
> instance, you wouldn't expect to run an i686 binary on an i386, even if
> the i6
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,
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 ca
On Fri, 26 Apr 2002, Joshua Slive wrote:
> 1. What if you want to log both the ident and the password? Your answer
> is probably "nobody uses ident anymore". In that case, we may eventually
...
> The environment approach just seems much cleaner to me.
When the module was created - the situati
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
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
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 loggi
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 fiel
+1 - especially for 2.0 where we do not care about breaking
processing scripts and what not.
Dw
--
Dirk-Willem van Gulik
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 acce
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 alw
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 wo
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.
use or toss - if used Rich Bowen promised to upda
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 s
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
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 al
> 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
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-f
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 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 rem
-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 T
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. :)
--
On Fri, Apr 26, 2002 at 02:16:51PM -0400, Cliff Woolley 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
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 co
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, 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 fu
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 confirm this patch compiles. Sorry.
Bill
==
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
> > 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
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 co
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-po
On Fri, Apr 26, 2002 at 11:13:55AM -0500, Rose, Billy wrote:
> 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 pres
> +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 is not good enough for me. :(
Optimizations th
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
> 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
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 start
> > +* 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
> >
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 sta
> +* 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
> + in
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
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> 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...
we already have something called envvars which can be used, but that
pollutes the current en
"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
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
- Origina
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 environ
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 w
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 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 VERS
> 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
58 matches
Mail list logo
