On Thu, 12 Jun 2003, Justin Erenkrantz wrote:
> What would happen if e weren't there and it were passed to
> APR_RING_SPLIT_TAIL? -- justin
By "weren't there," I assume you mean "were in some other brigade".
Then the supposed sequence of buckets represented by
APR_BRIGADE_FIRST(ctx->b)...APR_BU
On Thu, Jun 05, 2003 at 04:01:27PM -0400, Jeff Trawick wrote:
> seems like you could copy libgcc_s to Apache's lib directory... Apache's
> bin/envvars file already updates LD_LIBRARY_PATH to include that directory
This works just fine. Allows us to make a self-contained Apache
package. The admi
Title: RE: [PATCH] Avoid unnecessary brigade splits on core input and output filters. WAS: EOS or FLUSH buckets
Cliff,
I tested your code in core.c output filter and it works well.
Juan
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 12, 2
On Thu, Jun 12, 2003 at 05:55:10PM -0400, Cliff Woolley wrote:
> I should point out that the above code does one thing that my code does
> not: it allows for bucket e to be completely absent from ctx->b. (In
> which case ctx->b would be left completely empty at the end of the loop.)
> My code assu
> > On Thu, 12 Jun 2003, Justin Erenkrantz wrote:
> >
> > > for (bucket = APR_BUCKET_FIRST(ctx->b);
> > > bucket != e && bucket != APR_BRIGADE_LAST(ctx->b);
> > > bucket = APR_BUCKET_NEXT(bucket)) {
> > >apr_bucket_remove(bucket);
> > >APR_BRIGADE_INSERT_TAIL(b, bucket);
> > > }
On Thu, 12 Jun 2003, Juan Rivera wrote:
> Is your code assuming that b is empty? If so, I'm not sure we can make that
> assumption.
Nope, that is not an assumption. It works regardless of how many buckets
are in brigade b.
--Cliff
On Thu, 12 Jun 2003, Justin Erenkrantz wrote:
> I suggest that this be created as a macro called
> APR_BRIGADE_CONCAT_UNTIL() as I don't think understanding apr_ring.h
> should be a pre-req for writing filters. ;-) -- justin
I'm fine with that... I'll try to find some time tonight to add it to
Title: RE: [PATCH] Avoid unnecessary brigade splits on core input and output
filters. WAS: EOS or FLUSH buckets
My bad, never mind. You are fixing up the
ctx->b pointers. I'm going to try it out.
-Original Message-
From: Juan Rivera
[mailto:[EMAIL PROTECTED]
Sent: Thursday, Ju
Title: RE: [PATCH] Avoid unnecessary brigade splits on core input and output filters. WAS: EOS or FLUSH buckets
Cliff,
Is your code assuming that b is empty? If so, I'm not sure we can make that assumption.
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: Th
On Thu, Jun 12, 2003 at 05:07:32PM -0400, Cliff Woolley wrote:
> On Thu, 12 Jun 2003, Justin Erenkrantz wrote:
>
> > for (bucket = APR_BUCKET_FIRST(ctx->b);
> > bucket != e && bucket != APR_BRIGADE_LAST(ctx->b);
> > bucket = APR_BUCKET_NEXT(bucket)) {
> >apr_bucket_remove(bucket);
>
On Thu, 12 Jun 2003, Justin Erenkrantz wrote:
> for (bucket = APR_BUCKET_FIRST(ctx->b);
> bucket != e && bucket != APR_BRIGADE_LAST(ctx->b);
> bucket = APR_BUCKET_NEXT(bucket)) {
>apr_bucket_remove(bucket);
>APR_BRIGADE_INSERT_TAIL(b, bucket);
> }
No! Bad!! The whole beauty of
Juan Rivera wrote:
Have you guys ever considered making the size of the socket read buffer
configurable (default is 8K)?
not really, is it a problem?
Greg
Hi,
just a question here. What is the criteria used to list pending patches
in the status report?
A while back I've posted a patch to fix bug #9037 ->
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9037 and since I've
received positive feedback on it I was wondering what was preventing it
f
Have you guys ever considered making the size of the socket
read buffer configurable (default is 8K)?
Juan
Justin Erenkrantz wrote:
On Thu, Jun 12, 2003 at 02:48:20PM -0400, Jeff Trawick wrote:
Meanwhile, are there problems with 1.4.2 that our users have experienced?
Maybe there is no win here, but if 1.4.2 has no known problems then
maybe we should stick with that until the use of libtool 1.5 doesn'
> From: Jeff Trawick [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2003 8:48 PM
> One problem I know of with 1.5 is that it forces our configure to fail
> if some standard C++ autoconf checks fail. Since we don't care about
> C++, this isn't cool for Apache users.
>
> Based on discussio
On Thu, Jun 12, 2003 at 02:48:20PM -0400, Jeff Trawick wrote:
> Meanwhile, are there problems with 1.4.2 that our users have experienced?
>
> Maybe there is no win here, but if 1.4.2 has no known problems then
> maybe we should stick with that until the use of libtool 1.5 doesn't
> bring with it
One problem I know of with 1.5 is that it forces our configure to fail
if some standard C++ autoconf checks fail. Since we don't care about
C++, this isn't cool for Apache users.
Based on discussions on the libtool mailing list, I expect that a future
1.5.x release will allow packages like our
Title: [PATCH] mod_cache RFC compliance
Hello,
In order to accelerate the RFC compliance of mod_cache, I propose these two patches which fix two problems :
- It doesn't handle the Cache-Control directives (max-age, max-stale, min-fresh...) properly.
- It doesn't send a "If-Modified-Since" to
Matthew Hagerty wrote:
Greetings,
I was hoping to get confirmation that Apache uses a single process, and/or
thread for Apache 2.x, to perform logging, as opposed to each child
process/thread logging its own entries?
no, the logging provided with Apache (ErrorLog support, mod_log_config)
logs on
Rahul Kohli wrote:
I want for all Apache versions my code flow should be different then for Apache 1.3.19 based IBM HTTP Server and I want to use the same executable with same Makefile.
In general: If you need to discuss IHS-specific issues, send e-mail to
[EMAIL PROTECTED] and I'll find somebody
Hi,
After reading util_ldap in modules/experimental, i found some broken
stuff in the cache.
The shm was created in child init hook, and util_ldap_shm,
util_ldap_rmm, util_ldap_cache were declared as global in util_ldap_cache.h.
I tryied to make it running with worker mpm and it was very unstabl
Dear developers,
I am debugging on httpd 2.0.45.
I came across a strange scenario in the source code file
core.c,
I try to change the following function to handle an error
case
(See comments at "if (rv == 89)" ):
static apr_status_t core_output_filter(ap_filter_t *f,
apr_bucket_brigade *b)
{
..
Hi,
I have developed a C++ application for HP-UX - Apache Web Server.
Actually my requirement is:
I want for all Apache versions my code flow should be different then for Apache 1.3.19
based IBM HTTP Server and I want to use the same executable with same Makefile.
For e.g:
if (flag1)
--On Wednesday, June 11, 2003 5:14 PM -0400 Cliff Woolley
<[EMAIL PROTECTED]> wrote:
On Tue, 10 Jun 2003, Justin Erenkrantz wrote:
What you are really wanting to do is a partial concatenation of the brigade.
Something like (not there, but it could be easily added):
APR_BRIGADE_CONCAT_UNTIL(b, ct
25 matches
Mail list logo
