Re: challenge requirements

[Greg Stein <gs...@lyra.org>]

Okay... I haven't got to this completely. I went out to dinner and had many
drinks :-) ... The "set this aside" is easy; I've been spending most of the
time figuring out the proper strategy for spilling a too-large request off
to a file.

On Wed, Jun 28, 2000 at 03:04:27PM -0700, rbb@covalent.net wrote:
>...
> > IOW, is it fair to state that the current patch can go in *without* this
> > particular module/support structure? That simply showing that your challenge
> > is possible, will validate that the current patch can support it?
> 
> Maybe.  If you design ten new structures that are pretty complex, no.  If
> you design two or three obvious structures to support this, then of course
> this doesn't need to be rolled into the current patch.  Basically what I
> am saying is that if supporting this means changing the current patch
> drastically, then the current patch isn't the right patch.  Make
> sense?  do you agree?

Yes, yes.

I have defined two new structures and a bucket type at this point. There
will be a few new functions, but I haven't moved passed the data structures
yet (cuz of booze :-) and designing the spill strategy).

I might add a third structure for the spill mechanism (rather than sticking
with two, and overloading the meaning of one of those).

>...
> > This is just a quick read through. I may come back when I dig in.
> 
> Please come back as much as you need to.  Fair warning.  I have guests
> tonight.  I am stopping work after they have toured the city.  Once I stop
> for the day, I'm unlikely to check e-mail until tomorrow morning.  I'll
> answer your questions as soon as I get them though.

hehe... it ends up that I didn't get to this today/tonite either :-)

> > > 2)  No memory can be allocated out of r->pool.  If it is allocated out of
> > > r->pool, then the memory must be allocated for the length of the
> > > request.  Sub-pools are okay, but I will challenge them, and I will want a
> > > very good piece of psuedo-code to explain why the sub-pool won't require
> > > copying.
> > 
> > Agreed.
> > 
> > Note that r->pool and/or a subpool may be used to make a one-time allocation
> > of a fixed-size value (i.e. not proportional to the response size). This
> > should be okay. Agree?
> 
> I think so, but exactly what the buffer is used for may invalidate
> that.  I know I am being unclear.  I am sorry about that.  Tell you
> what, assume I agree with this.  If it turns out the memory allocation is
> "bad", then I will be required to give both great docs and incredibly
> psuedo-code or real code to prove it.  Sound fair?

Yup. I'm not worried about allocs at this point. I'm pondering on a clean
spill strategy and structure. Specifically, if a file descriptor comes down
the pipe, do you copy its contents into your spill file, or do you retain
the file as-is? The latter is obviously most efficient, so then what do you
do when you have a sequence of MEM-FD-MEM-FD-MEM-FD-MEM? How do you get each
of those mem chunks into the spill file, yet retain the interleaved files?
:-) ... I'll solve it cleanly, but it isn't a straight-forward problem :-)

>...
> > > > If I provide the structures and detailed pseudo-code, will that be
> > > > sufficient? I can do this today.
> > > 
> > > The more actual compile-able code there is, the better off we are.  One of
> > > the arguments you have been making is that your patch can do 99% of this
> > > today, as is.
> > 
> > Um. Then I was unclear. If I used the word "can", then I meant it in the
> > future tense (i.e. "it can do that [with changes]"). Let's rephrase as "my
> > patch could do this with straight-forward extensions."
> > 
> > Your "challenge" is in response to that statement :-). Fair enough.
> 
> My challenge is that if the current patch requires extensive changes to
> make it do what we are talking about, the patch isn't "the right
> solution".  If the changes are straight forward, and don't require months
> to make, then I think that is fine.

It won't be months. Should happen tomorrow. I've got a lunch, but I'll
complete the code then.

Cheers,
-g

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