httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject iovecs and grumpiness (was: Re: [PATCH] link-based filtering)
Date Mon, 26 Jun 2000 22:31:02 GMT
On Mon, Jun 26, 2000 at 02:09:04PM -0700, wrote:
> <quote>
> > > > It isn't mod_cgi that is going to use the iovec, it's mod_include.  That
> > > > is, unless mod_include is going to memcopy all of those into a BUFF.
> > > 
> > > Copying into a BUFF is what happens today, and I see no reason that it
> > > wouldn't or shouldn't in the future.
> </quote>
> Basically, modules have to do one of two things if they are using the char
> *'s.
> 1)  Re-implement ioblocks (because not all iovec implementations allow for
> more than 16 iovecs.  At least I believe there are limitations on the
> length in some implementations).
> 2)  Use a Buff structure to conglomerate all of the data.

Why do they need to do EITHER?

What is it with this? This is straight-forward coding. Take a look at my
version of the mod_gargle. There isn't a single notion of iovec, and there
is no BUFF employed (or other means to "conglomerate" data).

I am at a loss as to you are stating this "fact" of how a char* callback is
going to operate.

And what the heck is this notion about iovec implementations? I have zero
clue as to how that matters at all. Certainly, nothing in Apache is going to
call the platform's writev().

> Based on what you said above, it sure looks like you expect them to use a
> BUFF structure.  Unless you meant that there is a BUFF at the bottom of
> the chain, and within the chain they have to use iovec's or do strcpy's.

The BUFF is at the bottom. One of them. Just like today. I have said that
several times, and am getting really tired of saying it again.

I see no reason to have an iovec (neither example that I wrote uses one). If
a filter must set aside some content for later use, then damn straight it is
going to have to memcpy() the thing. There is nothing wrong with that, and
you are certainly not going to be able to avoid it either.

> This requires multiple memcpy's.  Regardless, if they re-implement
> ioblocks, they have to do multiple memcpy's, instead of the one that
> Apache can do if we remove all of the char *'s.

There isn't a single memcpy in EITHER of the examples I posted. Get your
facts straight. I'm getting very tired of having to explain this stuff, when
it seems readily apparent from the code. Geez. The code is only a few
hundred lines, and the bulk of that is simply to deal with the different
types of writing (but it all uses the same, underlying concept). There is
nothing complicated in there.

==> memcpy() is not always needed
==> BUFF is not needed
==> iovecs are not needed

Are you simply not going to be happy until I go and recode mod_include to
use a char* handler, and that I can demonstrate that the above is true? Or
can you stop railing off with unfounded suppositions and really think about
what I have written? I gave you the respect of examining your code very
carefully, and considering its operational model. My comments on its
drawbacks and coding style were all backed up with ample explanation, facts,
and examples. I don't believe that I ever made unfounded statements towards
your proposed patches, and I would request the same.


Greg Stein,

View raw message