apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <gr...@alum.wpi.edu>
Subject Re: [PATCH] brigade buffering.
Date Thu, 25 Jan 2001 23:16:51 GMT
At 06:09 PM 01/25/2001, rbb@covalent.net wrote:
> > >So, there are two answers to this that I see.  #1, tell
> > >the programmer that (s)he is out of luck if (s)he doesn't 
> understand
> > >the code.  #2, actually copy all the data.
> >
> > So then the rule has to be that if call a apr_brigade_* function 
> that
> > can generate more than APR_BUCKET_BUFF_SIZE data in a single call,
> > then that brigade has to be output before the buffer is reused or
> > goes out of scope?
> > It's hard to see how that fits well into a general brigade API.
>
>It's a trade-off.  I'm not saying this code is correct, this is the 
>first-stab, and it is a general idea or design.

I realize that, I was commenting that it while sometimes #1 is 
acceptable, it looks like it would be difficult to understand the 
rules, so that #2 would probably be the better approach.

> > One other optimization that I noticed would probably be useful 
> would
> > be to have apr_brigade_putstrs written at the same level as
> > apr_brigade_write such that you save the memcpy of 
> apr_brigade_write
> > after the apr_vsnprintf.
>
>You lost me here.  I am not at all worried about optimizations right 
>now.

I know, just pointing it out.

>My biggest problem with this paragraph, is that apr_vsnprintf 
>doesn't have
>anything to do with apr_brigade_putstrs and apr_brigade_write, so I 
>don't
>see the connection.

Sorry, apr_brigade_vprintf, not apr_brigade_putstrs.

-- 
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"


Mime
View raw message