httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: [PATCH] resubmit new and improved ap_vrprintf fix to handle > 4K
Date Tue, 11 Sep 2001 08:41:22 GMT
On Mon, 10 Sep 2001, Greg Stein wrote:

> On Mon, Sep 10, 2001 at 09:13:46PM -0700, dean gaudet wrote:
> > buhhh?
> >
> > you guys built a zero-copy infrastructure and you're putting in a one-copy
> > sprintf?
> sprintf varieties must be at least one-copy, based on our vformatter code
> (which BUFF used, too). It seems you're implying sprintf should be zero-copy
> also. ??

yeah sorry i was just thinking of the copies before write(2).  1.3
vformatter goes direct into the BUFF buffer which then goes to write(2)...
2.0 goes into a stack buffer then a heap buffer then to write(2).

> > i don't get it.  this new ap_rsprintf is less efficient than the
> > ap_bsprintf in apache-1.3.
> I don't doubt it. The primary intent for ap_r* was compatibility; the most
> optimal mechanism for delivering content is through the new brigade
> mechanisms (down thru the filter chain).

are other methods for people to write easy putc/puts/printf-style code in

> > also, wow, ap_rputc really sucks now.  that's a lot of code (in
> > buffer_output) compared to:
> >
> >     *buf++ = c;
> >
> > guess all your abstraction has hidden the real buffer and you can't do any
> > useful optimisations?
> At this point, we are not trying to optimize "around" the filter chain.
> Since we can't know what is next in the chain, buffer_output we must use
> ap_fwrite() to buffer the data.

in the case of a simple module just wanting to do putc/puts/printf-style
output i don't see why it can't always have a buffer mechanism similar to
the old BUFF.  even if it's being filtered or whatever, those steps happen
after the BUFF has flushed.

> In the future? Yah. Maybe we'll be able to do more, but that won't happen
> for a while.
> >...
> > oh ouch i gotta stop looking:
> >
> >     /* this will typically exit on the first test */
> >     for (f = r->output_filters; f != NULL; f = f->next)
> >         if (strcasecmp("OLD_WRITE", f->frec->name) == 0)
> >             break;
> >
> > i'm puking.  strcasecmp???? strings??
> Yah :-) It could be optimized by recording a flag in the request_rec,
> stating that the filter was inserted (rather than looking for it). The
> strcasecmp() shouldn't be necessary because we uppercase f->frec->name
> nowadays.
> Not that it will improve things overall, but there ya go. :-)

well, the flag wouldn't be necessary if the module itself made the choice
of having the new fancy (but complicated to use) output mechanisms, or if
it just wants a basic old-school BUFF.


View raw message