At 04:20 PM 10/03/2000, rbb@covalent.net wrote:
> > If you don't copy at all in ap_r*, you're setting yourself up for
> > trouble. You can't buffer this without copying:
> >
> > char buf[100];
> > int i;
> > int write = 0;
> >
> > for(i = 0; i < 100; ++i)
> > {
> > sprintf(buf, "This is line number %d\n", write++);
> > ap_rputs(buf, r);
> > }
> >
> > If you're already going to have to copy, why not coalesce at the
> same
> > time?
>
>We take care of this by using the setaside function. The reason not
>to coalesce, is that we don't know if we want to or not. Imaging a
>brigade that looks like:
But the setaside function has to copy the data. If you're already
going to copy it, why copy it here and then coalesce it in the core,
copying it again?
>immortal(1000 bytes) -> transient(50 bytes) -> heap (200 bytes)
How do you get a brigade like this using ap_r*? Are you mixing ap_r*
with regular bucket calls here? If you're trying to allow that, then
yes, you're not going to be able to coalesce anything because things
have to go into the current brigade right away. This is kind of like
using buffered and unbuffered output at the same time. You have to
finish up with the buffered output and flush the buffers before going
on to unbuffered output.
>If we coalesce, we end up copying 125 bytes, but only 20 of those
>need to be set-aside because they are stack data.
When you're using ap_r*, everything has to be set aside,
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
|