httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject sick of this shit (was: Re: code chunks for filter challenge)
Date Fri, 30 Jun 2000 02:25:53 GMT
On Thu, Jun 29, 2000 at 03:56:18PM -0700, rbb@covalent.net wrote:
> 
> > > But isn't that information lost when we go from bucket to char * filters?
> > 
> > Yes, it is lost.
> > 
> > There is no sense in continuing this email response if you focus on the
> > char* filters.
> 
> I've been focusing on the char * filters since the beginning.  This is
> where my issue is with your design.

Damn it. You're really starting to get me pissed off, and I'm quite unhappy
about this whole thing.

Look. If you want zero-copy when you set aside a whole buffer, it is
possible *if* the content generator and upstream filters provide the right
thing. After that filter delivers the content downstream, whether it makes
it to the network or not is entirely up to those filters.

You are suggesting that we have to have a scheme that is zero-copy across
the entire chain. That is just fucked.

Consider a content recoder that maps UTF-16 content into UTF-8 content. The
length is going to change, so you cannot operate in place. What comes into
the filter is TOTALLY LOST. Something else entirely goes out the other side
of that filter.

Well, guess what? That damn zero-copy that you keep insisting on just flew
right out the window.

Want to know more? That recoder is going to use a char* handler. Why?
Because it is so damned easy, and it exactly matches the semantics that a
recoder is going to need.

I sick of your bullshit about this filtering stuff.

"char* handlers are bad." My ass. For particular filtering applications,
they are totally applicable, and the appropriate design point.

"oh. there is a memcpy() in your al_setaside_bucket()". No shit. The caller
did an ap_rvputs(r, buf1, buf2, "some string", another_buf, NULL). We sure
as hell HAVE TO COPY that data into a long-lived pool.

You are so focused on the little fucking details and how you can say "oh, it
is bad here. it is bad there." that you aren't even looking at WHY certain
things exist. That memcpy() exists because it HAS TO BE THERE. There is
nothing you are every going to be able to design and build to avoid a
memcpy() for a set-aside when the content generator calls ap_rvputs(). It
must be done. Wake the hell up.


Your veto is real bullshit. It is supported only by manufactured excuses,
illogical assumptions, and impossible preconditions.

Regards,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message