Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "Charles Cutler" <charles@ruadh.com>
To: <new-httpd@apache.org>
Subject: RE: iovecs and grumpiness (was: Re: [PATCH] link-based filtering)
Date: Tue, 27 Jun 2000 12:54:51 +0100
Message-ID: <001401bfe02e$807482e0$8e06060a@biris.gateway>
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.21.0006261541440.17852-100000@koj.rkbloom.net>
Importance: Normal

please unsubscribe user from this mail list

___________________________________________

Charles Cutler
Ruadh Ltd
Tel - 00 44 (0)1334 654300
charles@ruadh.com
http://www.ruadh.com

-----Original Message-----
From: rbb@covalent.net [mailto:rbb@covalent.net]
Sent: 26 June 2000 23:47
To: new-httpd@apache.org
Subject: Re: iovecs and grumpiness (was: Re: [PATCH] link-based
filtering)


> > 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.

The problem is that you and I are attacking this very differently, and I
have been unable to explain what is in my head.

I have reviewed your code, and I am trying to explain where it falls
down.  Obviously, I am not doing a good job.

I am going to take a step back, and finish my patch (minor issues left),
and then I will try to explain in very clear terms what I am saying.  Do
not take my inability to find the right words to explain this as not
reviewing your patch.

It took me two days (and somebody else's help) to figure out what you
meant by saying modules would have to be written in an async manner, so I
am not the only one being unclear with regards to these patches.

Ryan

____________________________________________________________________________
___
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
----------------------------------------------------------------------------
---