> >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.
Ahhh, That makes much more sense. That function ne
At 06:09 PM 01/25/2001, [EMAIL PROTECTED] 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
th
> >However, you are correct that in general this is an issue, the
> >solution is to always copy the data, but that has other
> >drawbacks. 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
At 04:51 PM 01/25/2001, [EMAIL PROTECTED] wrote:
> FYI: this has the potential to fail miserably:
I need to think about these, but I think you are correct.
I can provide a walk-through of the code if you want. I decided it
was too long to post to the list.
I am not proposing that this is bullet-
> At 03:41 PM 01/25/2001, [EMAIL PROTECTED] wrote:
> >This general patch has been on new-httpd, but it really belongs
> >here. This is my general concept for how brigades should be buffered.
>
> FYI: this has the potential to fail miserably:
>
> char buffer[APR_BUCKET_BUFF_SIZE + 1];
>
At 03:41 PM 01/25/2001, [EMAIL PROTECTED] wrote:
This general patch has been on new-httpd, but it really belongs
here. This is my general concept for how brigades should be buffered.
FYI: this has the potential to fail miserably:
char buffer[APR_BUCKET_BUFF_SIZE + 1];
int i;
for(i = 0
> > > The problem with this type of optimization is that the brigade code
> > > cannot know the optimal size of a bucket -- only the next
> > > filter in the chain can know, since what is optimal will depend
> > > on what kind of processing is done next.
> >
> > However, the programmer knows what
> > Why write to the brigade instead of the top filter?
>
> Because we aren't always writing to the top filter. Sometimes, we are
> writing to a lower filter. This is the problem with current
> implementation.
I meant the top from the perspective of the writer (i.e., a lower
filter only knows a
This general patch has been on new-httpd, but it really belongs
here. This is my general concept for how brigades should be
buffered. There are some bugs here, and it is not a full solution. These
are basically meant as underlying functions, programs such as Apache would
need to put wrappers a
> > The problem is that it is impossible to do a lot of small writes to a
> > brigade efficiently. Take as an example, code that needs to add 20 five
> > byte buffers to brigade. There are two options:
> >
> > 1) bigbuff = apr_pstrcat(p, buf1, buf2, buf3, buf4, buf5, ...);
> > b = apr_buck
> > Can you put in words and some simple examples what's wrong with the API?
>
> The problem is that it is impossible to do a lot of small writes to a
> brigade efficiently. Take as an example, code that needs to add 20 five
> byte buffers to brigade. There are two options:
>
> 1) bigbuff = ap
--- Greg Stein <[EMAIL PROTECTED]> wrote:
> Now that we're actually using this function, I figured it was time to dig in
> and spend the time with this patch. :-)
Cool. Just so you know, I've been kind of out-of-touch with the list for a
while, since
the 1000+ messages that accumulated while I
> Can you put in words and some simple examples what's wrong with the API?
The problem is that it is impossible to do a lot of small writes to a
brigade efficiently. Take as an example, code that needs to add 20 five
byte buffers to brigade. There are two options:
1) bigbuff = apr_pstrcat(p,
On 25 Jan 2001 [EMAIL PROTECTED] wrote:
> Hoping that "cvs diff -u" is all I need to do to create unified
> diffs...
That's it. Thanks for the unified diff, it makes it much easier to review
the patch. :-)
Ryan
___
R
Hoping that "cvs diff -u" is all I need to do to create unified
diffs...
* open.c (apr_rename_file): Replaced use of unsupported function
MoveFileEx() with MoveFile() for
pre-Windows NT (Win95/98) OS levels. This
[moved from new-httpd]
Ryan,
Can you put in words and some simple examples what's wrong with the API?
I'm asking here as the buckets are part of APR aren't they?
david
- Original Message -
From: <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2001 5:13 PM
Subje
Welcome Mike. :-) I am sure I speak for everybody here when I say we are
very glad you have come to the party, and we look forward to your patches.
Ryan
On 25 Jan 2001 [EMAIL PROTECTED] wrote:
> Greetings, all. Mike Pilato here, Subversion developer, and first-
> time APR list poster. I've
* open.c (apr_open): Fixed deferencing of potentially NULL pointer
(and incorrect logic, at any rate) in call to
CreateFileA( ).
Index: open.c
===
RCS file: /home/cvspublic/apr/file_io/win32/o
Greetings, all. Mike Pilato here, Subversion developer, and first-
time APR list poster. I've found some bugs in the APR code that
only show up in Windows 95 and 98, so I plan to submit a few patches
in the very (perhaps even very *very*) near future. Anything you
might care to know about me you
> ben 01/01/24 14:52:57
>
> Modified:server config.c
>hooksapr_hooks.c
>include apr_hooks.h
> Log:
> The current hooking module is _not_ a debugging aid.
that's fine ... I just hope you grepped for all occurances ...
I normalized two variat
20 matches
Mail list logo
