BLECK!
Ok this is my 'fault'. Please note that EXACTLY this proposed code exists
and is used in the ssl core filter of httpd.
Before you go blasting to smithereens, could we please discuss the merits
of this approach? It's clear that every brigade application at some point
will FINALLY consume
On Tue, Jun 22, 2004 at 03:31:57PM -0500, William Rowe wrote:
BLECK!
Ok this is my 'fault'. Please note that EXACTLY this proposed code exists
and is used in the ssl core filter of httpd.
Before you go blasting to smithereens, could we please discuss the merits
of this approach? It's
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/07/01 22:25:44
Modified:buckets apr_buckets_alloc.c
include apr_buckets.h
Log:
an addition to the api to allow httpd mpm's to share an apr_allocator_t
between a thread pool and the thread's bucket
On Wed, Jul 02, 2003 at 02:03:39AM -0400, Cliff Woolley wrote:
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/07/01 22:25:44
Modified:buckets apr_buckets_alloc.c
include apr_buckets.h
Log:
an addition to the api to allow httpd mpm's to share
On Tue, 1 Jul 2003, Greg Stein wrote:
Eh? Why the flag? What is that for... doesn't the caller know when and if he
should clean up? So there shouldn't be a need for a flag...
The caller knows. But right now apr_buckets_alloc.c:alloc_cleanup() calls
apr_allocator_destroy(allocator) regardless
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-int is_metadata;
+enum {
+/** This bucket type represents actual data to send to the
client. */
+APR_BUCKET_DATA = 0,
+/** This bucket type represents metadata. */
+APR_BUCKET_METADATA
On Sun, Jun 02, 2002 at 12:42:30AM -0700, Ryan Bloom wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-int is_metadata;
+enum {
+/** This bucket type represents actual data to send to the
client. */
+APR_BUCKET_DATA = 0,
+/** This
On Sun, 2 Jun 2002, Ryan Bloom wrote:
+enum {
+/** This bucket type represents actual data to send to the
client. */
+APR_BUCKET_DATA = 0,
+/** This bucket type represents metadata. */
+APR_BUCKET_METADATA = 1
+} is_metadata;
By
On Fri, May 31, 2002 at 02:19:16PM -0700, Ryan Bloom wrote:
...
Length does always mean data, but length has nothing to do with this
discussion. As I said the other day, there are two types of metadata,
filter metadata, and request metadata. This flag currently refers only
to filter metadata
On Fri, May 31, 2002 at 02:08:02PM -0700, Ryan Bloom wrote:
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
On 31 May 2002 [EMAIL PROTECTED] wrote:
...
Log:
Make buckets advertise if they are filled with metadata or not.
Long-term, we most likely want to extend this so that
On 31 May 2002 [EMAIL PROTECTED] wrote:
rbb 2002/05/31 13:51:20
Modified:buckets apr_buckets_eos.c apr_buckets_file.c
apr_buckets_flush.c apr_buckets_heap.c
apr_buckets_mmap.c apr_buckets_pipe.c
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
On 31 May 2002 [EMAIL PROTECTED] wrote:
rbb 2002/05/31 13:51:20
Modified:buckets apr_buckets_eos.c apr_buckets_file.c
apr_buckets_flush.c apr_buckets_heap.c
On Fri, 31 May 2002, Ryan Bloom wrote:
I considered that, but I am actually thinking of the future, where there
are different types of data. For example, when we want to send the
headers down the filter stack as a part of the brigade, that is metadata
and should be marked as such. However,
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
On Fri, 31 May 2002, Ryan Bloom wrote:
I considered that, but I am actually thinking of the future, where
there
are different types of data. For example, when we want to send the
headers down the filter stack as a part of the brigade, that
On Fri, 31 May 2002, Ryan Bloom wrote:
Length does always mean data, but length has nothing to do with this
discussion.
Just to update everybody else, we just had a big smackdown discussion
about this on IRC. We had to cut it short for various reasons, though.
We'll pick it back up later
On Wed, Jan 23, 2002 at 12:46:59PM -0600, William A. Rowe, Jr. wrote:
-1
If flatten reads into memory, you must have len of apr_size_t.
Oh, come on. =)
You just said the apr_size_t was wrong because we could overflow.
Now, apr_off_t is wrong because it can't be read into memory.
What would
Eek!
When I mentioned _getline, _pgetline, and _split_line, I was referring to
functions that only working at CR/LF boundaries. Not flatten functions.
Those functions ought to be _flatten() and _pflatten(). Keeping the
_split_line, tho (and I imagine that might be the only one we'd use).
On Mon, Jan 21, 2002 at 07:08:43PM -0800, Greg Stein wrote:
Eek!
When I mentioned _getline, _pgetline, and _split_line, I was referring to
functions that only working at CR/LF boundaries. Not flatten functions.
Those functions ought to be _flatten() and _pflatten(). Keeping the
On 10 Aug 2001 [EMAIL PROTECTED] wrote:
+/**
+ * Remove all zero length buckets from the brigade.
+ * @param b The bucket brigade
+ */
+#define APR_BRIGADE_NORMALIZE(b) \
+do { \
+apr_bucket *e; \
+e = APR_BRIGADE_FIRST(b); \
+if
On Friday 10 August 2001 11:56, Cliff Woolley wrote:
On 10 Aug 2001 [EMAIL PROTECTED] wrote:
+/**
+ * Remove all zero length buckets from the brigade.
+ * @param b The bucket brigade
+ */
+#define APR_BRIGADE_NORMALIZE(b) \
+do { \
+apr_bucket *e; \
On 11 Apr 2001 [EMAIL PROTECTED] wrote:
jwoolley01/04/11 12:07:11
Modified:server error_bucket.c
.CHANGES
buckets apr_buckets_eos.c apr_buckets_file.c
apr_buckets_flush.c apr_buckets_heap.c
From: [EMAIL PROTECTED]
Sent: Tuesday, April 10, 2001 2:32 PM
wrowe 01/04/10 12:32:29
Modified:include apr_buckets.h
Log:
Another emit bites the dust
That should have read... the last apr-util (and apr) emit bites
the dust... both build clean today.
22 matches
Mail list logo
