You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@locus.apache.org on 2000/10/13 07:35:58 UTC
cvs commit: apache-2.0/src/modules/standard mod_include.c
rbb 00/10/12 22:35:58
Modified: src CHANGES
src/ap ap_buckets.c ap_buckets_eos.c ap_buckets_file.c
ap_buckets_heap.c ap_buckets_mmap.c
ap_buckets_pipe.c ap_buckets_simple.c
ap_buckets_socket.c
src/include ap_buckets.h
src/main http_core.c http_protocol.c util_filter.c
src/modules/experimental mod_charset_lite.c
src/modules/standard mod_include.c
Log:
Remove all function pointers from the ap_bucket type. These function
pointers are replaced with a global table that allows modules to register
their bucket types. Those bucket types are then allowed to be used in
the server processing. This also required removing all direct calls to
those functions. The ap_bucket type has an index into an array, so in
each ap_bucket_* function, we use that index to find the correct set of
functions.
Revision Changes Path
1.272 +5 -0 apache-2.0/src/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apache-2.0/src/CHANGES,v
retrieving revision 1.271
retrieving revision 1.272
diff -u -r1.271 -r1.272
--- CHANGES 2000/10/13 03:38:34 1.271
+++ CHANGES 2000/10/13 05:35:52 1.272
@@ -1,4 +1,9 @@
Changes with Apache 2.0a8
+ *) Remove the function pointers from the ap_bucket type. They have been
+ replaced with a global table. Modules are allowed to register bucket
+ types and use then use those buckets.
+ [Ryan Bloom]
+
*) mod_cgid: In the handler, shut down the Unix socket (only for write)
once we finish writing the request body to the cgi child process;
otherwise, the client doesn't hit EOF on stdin. Small request bodies
1.21 +60 -3 apache-2.0/src/ap/ap_buckets.c
Index: ap_buckets.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- ap_buckets.c 2000/10/03 17:56:02 1.20
+++ ap_buckets.c 2000/10/13 05:35:52 1.21
@@ -62,15 +62,46 @@
#endif
#include "ap_buckets.h"
+static apr_array_header_t *bucket_types;
+
API_EXPORT(apr_status_t) ap_bucket_destroy(ap_bucket *e)
{
- if (e->destroy) {
- e->destroy(e->data);
+ ap_bucket_type *type = (ap_bucket_type *)bucket_types->elts;
+ if (type[e->type].destroy) {
+ type[e->type].destroy(e->data);
}
free(e);
return APR_SUCCESS;
}
+API_EXPORT(apr_status_t) ap_bucket_read(ap_bucket *e, const char **str,
+ apr_ssize_t *len, int block)
+{
+ ap_bucket_type *type = (ap_bucket_type *)bucket_types->elts;
+ if (type[e->type].read) {
+ return type[e->type].read(e, str, len, block);
+ }
+ return APR_ENOTIMPL;
+}
+
+API_EXPORT(apr_status_t) ap_bucket_setaside(ap_bucket *e)
+{
+ ap_bucket_type *type = (ap_bucket_type *)bucket_types->elts;
+ if (type[e->type].setaside) {
+ return type[e->type].setaside(e);
+ }
+ return APR_ENOTIMPL;
+}
+
+API_EXPORT(apr_status_t) ap_bucket_split(ap_bucket *e, apr_off_t point)
+{
+ ap_bucket_type *type = (ap_bucket_type *)bucket_types->elts;
+ if (type[e->type].split) {
+ return type[e->type].split(e, point);
+ }
+ return APR_ENOTIMPL;
+}
+
static apr_status_t ap_brigade_cleanup(void *data)
{
ap_bucket_brigade *b = data;
@@ -137,7 +168,7 @@
AP_BRIGADE_FOREACH(e, b) {
if (nvec-- == 0)
break;
- e->read(e, (const char **)&vec->iov_base, &iov_len, 0);
+ ap_bucket_read(e, (const char **)&vec->iov_base, &iov_len, 0);
vec->iov_len = iov_len; /* set indirectly in case size differs */
++vec;
}
@@ -209,3 +240,29 @@
return res;
}
+
+void ap_init_bucket_types(apr_pool_t *p)
+{
+ bucket_types = apr_make_array(p, 1, sizeof(ap_bucket_type));
+ ap_bucket_heap_register(p);
+ ap_bucket_transient_register(p);
+ ap_bucket_file_register(p);
+ ap_bucket_mmap_register(p);
+ ap_bucket_immortal_register(p);
+ ap_bucket_socket_register(p);
+ ap_bucket_pipe_register(p);
+ ap_bucket_eos_register(p);
+}
+
+int ap_insert_bucket_type(ap_bucket_type *type)
+{
+ ap_bucket_type *newone = (ap_bucket_type *)apr_push_array(bucket_types);
+
+ newone->read = type->read;
+ newone->setaside = type->setaside;
+ newone->destroy = type->destroy;
+ newone->split = type->split;
+
+ return bucket_types->nelts - 1;
+}
+
1.7 +20 -6 apache-2.0/src/ap/ap_buckets_eos.c
Index: ap_buckets_eos.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_eos.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ap_buckets_eos.c 2000/09/14 02:17:47 1.6
+++ ap_buckets_eos.c 2000/10/13 05:35:52 1.7
@@ -56,6 +56,8 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int eos_type;
+
static apr_status_t eos_read(ap_bucket *b, const char **str,
apr_ssize_t *len, int block)
{
@@ -67,13 +69,9 @@
API_EXPORT(ap_bucket *) ap_bucket_make_eos(ap_bucket *b)
{
b->length = AP_END_OF_BRIGADE;
-
- b->type = AP_BUCKET_EOS;
- b->read = eos_read;
- b->setaside = NULL;
- b->split = NULL;
- b->destroy = NULL;
b->data = NULL;
+
+ b->type = eos_type;
return b;
}
@@ -81,4 +79,20 @@
API_EXPORT(ap_bucket *) ap_bucket_create_eos(void)
{
ap_bucket_do_create(ap_bucket_make_eos(b));
+}
+
+void ap_bucket_eos_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+ type.read = eos_read;
+ type.setaside = NULL;
+ type.split = NULL;
+ type.destroy = NULL;
+
+ eos_type = ap_insert_bucket_type(&type);
+}
+
+int ap_eos_type(void)
+{
+ return eos_type;
}
1.3 +21 -5 apache-2.0/src/ap/ap_buckets_file.c
Index: ap_buckets_file.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_file.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ap_buckets_file.c 2000/10/12 18:01:28 1.2
+++ ap_buckets_file.c 2000/10/13 05:35:53 1.3
@@ -57,6 +57,8 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int file_type;
+
/* XXX: We should obey the block flag */
static apr_status_t file_read(ap_bucket *e, const char **str,
apr_ssize_t *len, int block)
@@ -121,13 +123,9 @@
f->fd = fd;
f->offset = offset;
- b->type = AP_BUCKET_FILE;
+ b->type = file_type;
b->data = f;
b->length = len;
- b->destroy = NULL;
- b->read = file_read;
- b->setaside = NULL;
- b->split = NULL;
return b;
}
@@ -136,3 +134,21 @@
{
ap_bucket_do_create(ap_bucket_make_file(b, fd, offset, len));
}
+
+void ap_bucket_file_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.destroy = NULL;
+ type.read = file_read;
+ type.setaside = NULL;
+ type.split = NULL;
+
+ file_type = ap_insert_bucket_type(&type);
+}
+
+int ap_file_type(void)
+{
+ return file_type;
+}
+
1.11 +19 -5 apache-2.0/src/ap/ap_buckets_heap.c
Index: ap_buckets_heap.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_heap.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ap_buckets_heap.c 2000/09/04 05:42:20 1.10
+++ ap_buckets_heap.c 2000/10/13 05:35:53 1.11
@@ -56,6 +56,7 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int heap_type;
/*
* The size of heap bucket memory allocations.
* XXX: This is currently a guess and should be adjusted to an
@@ -127,11 +128,7 @@
return NULL;
}
- b->type = AP_BUCKET_HEAP;
- b->split = ap_bucket_split_shared;
- b->destroy = heap_destroy;
- b->read = heap_read;
- b->setaside = NULL;
+ b->type = heap_type;
if (w)
*w = length;
@@ -143,4 +140,21 @@
const char *buf, apr_size_t length, int copy, apr_ssize_t *w)
{
ap_bucket_do_create(ap_bucket_make_heap(b, buf, length, copy, w));
+}
+
+void ap_bucket_heap_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.split = ap_bucket_split_shared;
+ type.destroy = heap_destroy;
+ type.read = heap_read;
+ type.setaside = NULL;
+
+ heap_type = ap_insert_bucket_type(&type);
+}
+
+int ap_heap_type(void)
+{
+ return heap_type;
}
1.11 +19 -5 apache-2.0/src/ap/ap_buckets_mmap.c
Index: ap_buckets_mmap.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_mmap.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ap_buckets_mmap.c 2000/10/04 12:01:14 1.10
+++ ap_buckets_mmap.c 2000/10/13 05:35:53 1.11
@@ -56,6 +56,8 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int mmap_type;
+
static apr_status_t mmap_read(ap_bucket *b, const char **str,
apr_ssize_t *length, int block)
{
@@ -104,11 +106,7 @@
return NULL;
}
- b->type = AP_BUCKET_MMAP;
- b->split = ap_bucket_split_shared;
- b->destroy = mmap_destroy;
- b->read = mmap_read;
- b->setaside = NULL;
+ b->type = mmap_type;
return b;
}
@@ -118,4 +116,20 @@
apr_mmap_t *mm, apr_off_t start, apr_size_t length)
{
ap_bucket_do_create(ap_bucket_make_mmap(b, mm, start, length));
+}
+
+void ap_bucket_mmap_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+ type.split = ap_bucket_split_shared;
+ type.destroy = mmap_destroy;
+ type.read = mmap_read;
+ type.setaside = NULL;
+
+ mmap_type = ap_insert_bucket_type(&type);
+}
+
+int ap_mmap_type(void)
+{
+ return mmap_type;
}
1.12 +20 -5 apache-2.0/src/ap/ap_buckets_pipe.c
Index: ap_buckets_pipe.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_pipe.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ap_buckets_pipe.c 2000/09/23 00:01:35 1.11
+++ ap_buckets_pipe.c 2000/10/13 05:35:53 1.12
@@ -57,6 +57,8 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int pipe_type;
+
/* XXX: We should obey the block flag */
static apr_status_t pipe_read(ap_bucket *a, const char **str,
apr_ssize_t *len, int block)
@@ -112,12 +114,8 @@
* stream so the bucket(s) that it sets aside will be the heap
* buckets created by pipe_read() above.
*/
- b->type = AP_BUCKET_PIPE;
+ b->type = pipe_type;
b->length = -1;
- b->setaside = NULL;
- b->destroy = NULL;
- b->split = NULL;
- b->read = pipe_read;
b->data = p;
return b;
@@ -126,4 +124,21 @@
API_EXPORT(ap_bucket *) ap_bucket_create_pipe(apr_file_t *p)
{
ap_bucket_do_create(ap_bucket_make_pipe(b, p));
+}
+
+void ap_bucket_pipe_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.setaside = NULL;
+ type.destroy = NULL;
+ type.split = NULL;
+ type.read = pipe_read;
+
+ pipe_type = ap_insert_bucket_type(&type);
+}
+
+int ap_pipe_type(void)
+{
+ return pipe_type;
}
1.6 +39 -7 apache-2.0/src/ap/ap_buckets_simple.c
Index: ap_buckets_simple.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_simple.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ap_buckets_simple.c 2000/09/17 18:52:46 1.5
+++ ap_buckets_simple.c 2000/10/13 05:35:53 1.6
@@ -57,6 +57,9 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int immortal_type;
+static int transient_type;
+
/*
* We can't simplify this function by using an ap_bucket_make function
* because we aren't sure of the exact type of this bucket.
@@ -116,12 +119,8 @@
bd->start = buf;
bd->end = buf+length;
- b->type = AP_BUCKET_IMMORTAL;
+ b->type = immortal_type;
b->length = length;
- b->setaside = NULL;
- b->destroy = free;
- b->split = simple_split;
- b->read = simple_read;
b->data = bd;
return b;
@@ -133,6 +132,23 @@
ap_bucket_do_create(ap_bucket_make_immortal(b, buf, length));
}
+void ap_bucket_immortal_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.setaside = NULL;
+ type.destroy = free;
+ type.split = simple_split;
+ type.read = simple_read;
+
+ immortal_type = ap_insert_bucket_type(&type);
+}
+
+int ap_immortal_type(void)
+{
+ return immortal_type;
+}
+
/*
* XXX: This function could do with some tweaking to reduce memory
* usage in various cases, e.g. share buffers in the heap between all
@@ -167,8 +183,7 @@
if (b == NULL) {
return NULL;
}
- b->type = AP_BUCKET_TRANSIENT;
- b->setaside = transient_setaside;
+ b->type = transient_type;
return b;
}
@@ -176,4 +191,21 @@
const char *buf, apr_size_t length)
{
ap_bucket_do_create(ap_bucket_make_transient(b, buf, length));
+}
+
+void ap_bucket_transient_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.destroy = NULL;
+ type.read = NULL;
+ type.setaside = transient_setaside;
+ type.split = NULL;
+
+ transient_type = ap_insert_bucket_type(&type);
+}
+
+int ap_transient_type(void)
+{
+ return transient_type;
}
1.2 +20 -5 apache-2.0/src/ap/ap_buckets_socket.c
Index: ap_buckets_socket.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/ap/ap_buckets_socket.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ap_buckets_socket.c 2000/10/10 22:09:25 1.1
+++ ap_buckets_socket.c 2000/10/13 05:35:53 1.2
@@ -57,6 +57,8 @@
#include "ap_buckets.h"
#include <stdlib.h>
+static int socket_type;
+
/* XXX: We should obey the block flag */
static apr_status_t socket_read(ap_bucket *a, const char **str,
apr_ssize_t *len, int block)
@@ -107,12 +109,8 @@
* Note that typically the socket is allocated from the connection pool
* so it will disappear when the connection is finished.
*/
- b->type = AP_BUCKET_SOCKET;
+ b->type = socket_type;
b->length = -1;
- b->setaside = NULL;
- b->destroy = NULL;
- b->split = NULL;
- b->read = socket_read;
b->data = p;
return b;
@@ -121,4 +119,21 @@
API_EXPORT(ap_bucket *) ap_bucket_create_socket(apr_socket_t *p)
{
ap_bucket_do_create(ap_bucket_make_socket(b, p));
+}
+
+void ap_bucket_socket_register(apr_pool_t *p)
+{
+ ap_bucket_type type;
+
+ type.setaside = NULL;
+ type.destroy = NULL;
+ type.split = NULL;
+ type.read = socket_read;
+
+ socket_type = ap_insert_bucket_type(&type);
+}
+
+int ap_socket_type(void)
+{
+ return socket_type;
}
1.35 +58 -21 apache-2.0/src/include/ap_buckets.h
Index: ap_buckets.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_buckets.h,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- ap_buckets.h 2000/10/12 18:01:29 1.34
+++ ap_buckets.h 2000/10/13 05:35:55 1.35
@@ -121,21 +121,6 @@
* routines, this enum will be a huge performance benefit, so we leave it
* alone.
*/
-typedef enum {
- AP_BUCKET_HEAP,
- AP_BUCKET_TRANSIENT,
- AP_BUCKET_FILE,
- AP_BUCKET_MMAP,
- AP_BUCKET_IMMORTAL,
- AP_BUCKET_POOL,
- AP_BUCKET_SOCKET,
- AP_BUCKET_PIPE,
- AP_BUCKET_EOS /* End-of-stream bucket. Special case to say this is
- * the end of the brigade so all data should be sent
- * immediately.
- */
-} ap_bucket_type_e;
-
#define AP_END_OF_BRIGADE -1
/**
@@ -160,7 +145,7 @@
AP_RING_ENTRY(ap_bucket) link;
/** The type of bucket. These types can be found in the enumerated
* type above */
- ap_bucket_type_e type;
+ int type;
/** type-dependent data hangs off this pointer */
void *data;
/** The length of the data in the bucket. This could have been implemented
@@ -169,12 +154,10 @@
* the value of this field will be -1.
*/
apr_off_t length;
-
- /** @tip all of these function pointers may be replaced by some
- * other means for getting to the functions, like a an index into
- * a table. In any case, these functions will always be available.
- */
+};
+typedef struct ap_bucket_type ap_bucket_type;
+struct ap_bucket_type {
/**
* Free the private data and any resources used by the bucket
* (if they aren't shared with another bucket).
@@ -458,6 +441,14 @@
/* ***** Bucket Functions ***** */
/**
+ * Initialize the core implemented bucket types. Once this is done,
+ * it is possible to add new bucket types to the server
+ * @param p The pool to allocate the array out of.
+ * @deffunc void ap_init_bucket_types(apr_pool_t *p)
+ */
+void ap_init_bucket_types(apr_pool_t *p);
+
+/**
* free the resources used by a bucket. If multiple buckets refer to
* the same resource it is freed when the last one goes away.
* @param e The bucket to destroy
@@ -465,6 +456,52 @@
*/
API_EXPORT(apr_status_t) ap_bucket_destroy(ap_bucket *e);
+/**
+ * read the data from the bucket
+ * @param e The bucket to read from
+ * @param str The location to store the data in
+ * @param len The amount of data read
+ * @param block Whether the read function blocks
+ * @deffunc apr_status_t ap_bucket_read(ap_bucket *e, const char **str, apr_ssize_t *len, int block)
+ */
+API_EXPORT(apr_status_t) ap_bucket_read(ap_bucket *e, const char **str,
+ apr_ssize_t *len, int block);
+
+/**
+ * Setaside data so that stack data is not destroyed on returning from
+ * the function
+ * @param e The bucket to setaside
+ * @deffunc apr_status_t ap_bucket_setaside(ap_bucket *e)
+ */
+API_EXPORT(apr_status_t) ap_bucket_setaside(ap_bucket *e);
+
+/**
+ * Split one bucket in two.
+ * @param e The bucket to split
+ * @param point The location to split the bucket at
+ * @deffunc apr_status_t ap_bucket_split(ap_bucket *e, apr_off_t point)
+ */
+API_EXPORT(apr_status_t) ap_bucket_split(ap_bucket *e, apr_off_t point);
+
+void ap_bucket_file_register(apr_pool_t *p);
+void ap_bucket_heap_register(apr_pool_t *p);
+void ap_bucket_transient_register(apr_pool_t *p);
+void ap_bucket_mmap_register(apr_pool_t *p);
+void ap_bucket_immortal_register(apr_pool_t *p);
+void ap_bucket_socket_register(apr_pool_t *p);
+void ap_bucket_pipe_register(apr_pool_t *p);
+void ap_bucket_eos_register(apr_pool_t *p);
+
+int ap_file_type(void);
+int ap_heap_type(void);
+int ap_transient_type(void);
+int ap_mmap_type(void);
+int ap_immortal_type(void);
+int ap_socket_type(void);
+int ap_pipe_type(void);
+int ap_eos_type(void);
+
+int ap_insert_bucket_type(ap_bucket_type *type);
/* ***** Shared reference-counted buckets ***** */
1.166 +15 -9 apache-2.0/src/main/http_core.c
Index: http_core.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/main/http_core.c,v
retrieving revision 1.165
retrieving revision 1.166
diff -u -r1.165 -r1.166
--- http_core.c 2000/10/12 18:01:30 1.165
+++ http_core.c 2000/10/13 05:35:55 1.166
@@ -3095,14 +3095,14 @@
ap_bucket_destroy(destroy_me);
destroy_me = NULL;
}
- if ((e->type == AP_BUCKET_EOS) || (e->type == AP_BUCKET_FILE) ||
- (e->type == AP_BUCKET_PIPE)) {
+ if ((e->type == ap_eos_type()) || (e->type == ap_file_type()) ||
+ (e->type == ap_pipe_type())) {
pass_the_brigade = 1;
}
else {
const char *str;
apr_ssize_t n;
- rv = e->read(e, &str, &n, 0);
+ rv = ap_bucket_read(e, &str, &n, 0);
if (rv != APR_SUCCESS) {
/* XXX: log error */
return rv;
@@ -3204,7 +3204,7 @@
char chunk_hdr[20]; /* enough space for the snprintf below */
AP_BRIGADE_FOREACH(e, b) {
- if (e->type == AP_BUCKET_EOS) {
+ if (e->type == ap_eos_type()) {
/* there shouldn't be anything after the eos */
eos = e;
break;
@@ -3214,7 +3214,7 @@
const char *data;
apr_ssize_t len;
- rv = e->read(e, &data, &len, 1);
+ rv = ap_bucket_read(e, &data, &len, 1);
if (rv != APR_SUCCESS) {
return rv;
}
@@ -3378,10 +3378,10 @@
nbytes = 0; /* in case more points to another brigade */
more = NULL;
AP_BRIGADE_FOREACH(e, b) {
- if (e->type == AP_BUCKET_EOS) {
+ if (e->type == ap_eos_type()) {
break;
}
- else if (e->type == AP_BUCKET_FILE) {
+ else if (e->type == ap_file_type()) {
ap_bucket_file *a = e->data;
/* Assume there is at most one AP_BUCKET_FILE in the brigade */
fd = a->fd;
@@ -3391,7 +3391,7 @@
else {
const char *str;
apr_ssize_t n;
- rv = e->read(e, &str, &n, 0);
+ rv = ap_bucket_read(e, &str, &n, 0);
if (n) {
nbytes += n;
if (!fd) {
@@ -3420,7 +3420,7 @@
/* Completed iterating over the brigades, now determine if we want to
* buffer the brigade or send the brigade out on the network
*/
- if (!fd && (!more) && (nbytes < MIN_SIZE_TO_WRITE) && (e->type != AP_BUCKET_EOS)) {
+ if (!fd && (!more) && (nbytes < MIN_SIZE_TO_WRITE) && (e->type != ap_eos_type())) {
ap_save_brigade(f, &ctx->b, &b);
return APR_SUCCESS;
}
@@ -3498,6 +3498,11 @@
{ NULL, NULL }
};
+static void core_pre_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp)
+{
+ ap_init_bucket_types(pconf);
+}
+
static void core_post_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp, server_rec *s)
{
ap_set_version(pconf);
@@ -3536,6 +3541,7 @@
static void register_hooks(void)
{
+ ap_hook_pre_config(core_pre_config, NULL, NULL, AP_HOOK_REALLY_FIRST);
ap_hook_post_config(core_post_config,NULL,NULL,AP_HOOK_REALLY_FIRST);
ap_hook_translate_name(ap_core_translate,NULL,NULL,AP_HOOK_REALLY_LAST);
ap_hook_pre_connection(ap_pre_http_connection,NULL,NULL,
1.167 +7 -7 apache-2.0/src/main/http_protocol.c
Index: http_protocol.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/main/http_protocol.c,v
retrieving revision 1.166
retrieving revision 1.167
diff -u -r1.166 -r1.167
--- http_protocol.c 2000/10/13 03:12:54 1.166
+++ http_protocol.c 2000/10/13 05:35:56 1.167
@@ -895,7 +895,7 @@
e = AP_BRIGADE_FIRST(b);
while (e != AP_BRIGADE_SENTINEL(b)) {
- e->read(e, &ignore, &len, 0);
+ ap_bucket_read(e, &ignore, &len, 0);
if (remain <= len) {
break;
}
@@ -904,7 +904,7 @@
}
if (e != AP_BRIGADE_SENTINEL(b)) {
if (remain <= len) {
- e->split(e, remain);
+ ap_bucket_split(e, remain);
remain = 0;
}
bb = ap_brigade_split(b, AP_BUCKET_NEXT(e));
@@ -918,13 +918,13 @@
}
AP_BRIGADE_FOREACH(e, b) {
- if ((rv = e->read(e, (const char **)&buff, &len, 0)) != APR_SUCCESS) {
+ if ((rv = ap_bucket_read(e, (const char **)&buff, &len, 0)) != APR_SUCCESS) {
return rv;
}
pos = memchr(buff, ASCII_LF, len);
if (pos != NULL) {
- e->split(e, pos - buff + 1);
+ ap_bucket_split(e, pos - buff + 1);
bb = ap_brigade_split(b, AP_BUCKET_NEXT(e));
ctx->b = bb;
return APR_SUCCESS;
@@ -970,7 +970,7 @@
ap_bucket_destroy(e);
continue;
}
- retval = e->read(e, &temp, &length, 0);
+ retval = ap_bucket_read(e, &temp, &length, 0);
if (retval != APR_SUCCESS) {
total = ((length < 0) && (total == 0)) ? -1 : total;
@@ -2428,9 +2428,9 @@
total = 0;
do {
- rv = b->read(b, &tempbuf, &len_read, 0);
+ rv = ap_bucket_read(b, &tempbuf, &len_read, 0);
if (len_to_read < b->length) { /* shouldn't happen */
- b->split(b, len_to_read);
+ ap_bucket_split(b, len_to_read);
}
else {
len_to_read = len_read;
1.30 +2 -3 apache-2.0/src/main/util_filter.c
Index: util_filter.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/main/util_filter.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- util_filter.c 2000/10/13 00:02:06 1.29
+++ util_filter.c 2000/10/13 05:35:56 1.30
@@ -212,7 +212,7 @@
API_EXPORT(apr_status_t) ap_pass_brigade(ap_filter_t *next, ap_bucket_brigade *bb)
{
if (next) {
- if (AP_BRIGADE_LAST(bb)->type == AP_BUCKET_EOS && next->r) {
+ if (AP_BRIGADE_LAST(bb)->type == ap_eos_type() && next->r) {
next->r->eos_sent = 1;
}
return next->frec->filter_func.out_func(next, bb);
@@ -234,8 +234,7 @@
}
AP_RING_FOREACH(e, &(*b)->list, ap_bucket, link) {
- if (e->setaside)
- e->setaside(e);
+ ap_bucket_setaside(e);
}
AP_BRIGADE_CONCAT(*saveto, *b);
}
1.24 +1 -1 apache-2.0/src/modules/experimental/mod_charset_lite.c
Index: mod_charset_lite.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/modules/experimental/mod_charset_lite.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- mod_charset_lite.c 2000/10/05 12:01:48 1.23
+++ mod_charset_lite.c 2000/10/13 05:35:57 1.24
@@ -688,7 +688,7 @@
}
break;
}
- rv = dptr->read(dptr, &cur_str, &cur_len, 0);
+ rv = ap_bucket_read(dptr, &cur_str, &cur_len, 0);
if (rv != APR_SUCCESS) {
done = 1;
ctx->ees = EES_BUCKET_READ;
1.66 +14 -14 apache-2.0/src/modules/standard/mod_include.c
Index: mod_include.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/modules/standard/mod_include.c,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- mod_include.c 2000/10/05 11:21:26 1.65
+++ mod_include.c 2000/10/13 05:35:57 1.66
@@ -190,10 +190,10 @@
int state = 0;
do {
- if (dptr->type == AP_BUCKET_EOS) {
+ if (dptr->type == ap_eos_type()) {
break;
}
- dptr->read(dptr, &buf, &len, 0);
+ ap_bucket_read(dptr, &buf, &len, 0);
/* XXX handle retcodes */
if (len == 0) { /* end of pipe? */
break;
@@ -210,10 +210,10 @@
* on what we are searching for.
*/
if (str[0] == '<') {
- dptr->split(dptr, c - buf - strlen(str));
+ ap_bucket_split(dptr, c - buf - strlen(str));
}
else {
- dptr->split(dptr, c - buf);
+ ap_bucket_split(dptr, c - buf);
}
return AP_BUCKET_NEXT(dptr);
}
@@ -348,7 +348,7 @@
/* Remove all whitespace */
while (dptr) {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str + *offset;
while (c - str < length) {
if (!apr_isspace(*c)) {
@@ -365,14 +365,14 @@
if (*c == '-') {
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
if (*c == '-') {
do {
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
} while (apr_isspace(*c));
@@ -397,7 +397,7 @@
*(t++) = apr_tolower(*c);
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
}
@@ -408,7 +408,7 @@
while (apr_isspace(*c)) {
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
}
@@ -420,7 +420,7 @@
do {
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
} while (apr_isspace(*c));
@@ -434,7 +434,7 @@
while (1) {
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
if (t - tag == tagbuf_len) {
@@ -446,7 +446,7 @@
*(t++) = *c; /* Add backslash */
c++;
if (c == '\0') {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
c = str;
}
if (*c == term) { /* Only if */
@@ -478,7 +478,7 @@
--len;
while (dptr) {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
/* need to start past the <!--#
*/
c = str + strlen(STARTING_SEQUENCE);
@@ -496,7 +496,7 @@
/* now get directive */
while (dptr) {
if (c - str >= length) {
- dptr->read(dptr, &str, &length, 0);
+ ap_bucket_read(dptr, &str, &length, 0);
}
while (c - str < length) {
if (d - dest == (int)len) {
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> On Fri, 13 Oct 2000 rbb@covalent.net wrote:
>
> > > I'm completely with Jeff on this one. I see no gains, and only negatives, in
> > > this "improvement". Shrinking the bucket size buys us very little, and (as
> > > Jeff says) the enumerated type is only important for us to write code to
> > > detect a few, special types. Obviously, we couldn't have code to look for a
> > > third-party type, so it doesn't matter what their bucket type is.
> > >
> > > In fact, I'd formalize it and introduce AP_BUCKET_TYPE_EXTENSION. All
> > > extensions to the bucket system can use that.
>
> BTW, that won't work. Imagine a bucket that mod_perl creates and wants to
> use to do some special processing with. Using the same type as is used
> for an SSL socket bucket would break that completely.
>
> Ryan
That is where ap_get-me-a-bucket-type() comes in. A module
implementing a custom bucket type can then get a unique id which
doesn't conflict with the ids of core bucket types.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by rb...@covalent.net.
On Fri, 13 Oct 2000 rbb@covalent.net wrote:
> > I'm completely with Jeff on this one. I see no gains, and only negatives, in
> > this "improvement". Shrinking the bucket size buys us very little, and (as
> > Jeff says) the enumerated type is only important for us to write code to
> > detect a few, special types. Obviously, we couldn't have code to look for a
> > third-party type, so it doesn't matter what their bucket type is.
> >
> > In fact, I'd formalize it and introduce AP_BUCKET_TYPE_EXTENSION. All
> > extensions to the bucket system can use that.
BTW, that won't work. Imagine a bucket that mod_perl creates and wants to
use to do some special processing with. Using the same type as is used
for an SSL socket bucket would break that completely.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by rb...@covalent.net.
> > No, I'm in no hurry to go any further down this path. I don't think
> > what is there already is worthwhile.
> >
> > We don't have better performance and we don't need the change in order
> > to allow modules to implement their own bucket types.
>
> I'm completely with Jeff on this one. I see no gains, and only negatives, in
> this "improvement". Shrinking the bucket size buys us very little, and (as
> Jeff says) the enumerated type is only important for us to write code to
> detect a few, special types. Obviously, we couldn't have code to look for a
> third-party type, so it doesn't matter what their bucket type is.
>
> In fact, I'd formalize it and introduce AP_BUCKET_TYPE_EXTENSION. All
> extensions to the bucket system can use that.
>
> Ryan: will you back that change out?
There are a couple of major improvements that haven't been discussed yet
that this does buy us.
#1) The ability to let the bucket type grow and mature without requiring
us to re-compile the whole server. I know binary compatability isn't a
big issue, but it is there.
#2) We go from making five assignments when creating buckets to making
one. This is a performance improvement when creating buckets.
#3) This mimics FreeBSD's kobj code, the guy who did that work did a
thorough performance analysis, and found only a negligable performance hit
came with the redirection. Granted, we will see a bigger hit until we
move to a pointer/macro based system, but that would only take a few hours
to implement.
The arguments against this so far have been performance, which I
personally don't agree with, and the fact that we can't tell what type we
are, which is solvable in this framework. This is far more flexible, and
it keeps the bucket size smaller, in fact we shrunk it by about half. Not
to mention that this improvement was mentioned in the big filter meeting,
where everybody generally agreed that getting the function pointers out of
the bucket type was a good idea.
I would prefer to hear from some of the other people before I back this
out. I know Tony was planning on doing this at some point, but he is
currently in the middle of moving I believe.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Oct 13, 2000 at 03:25:27PM -0400, Jeff Trawick wrote:
> rbb@covalent.net writes:
>
> > I had planned on letting this code work for a few days before making these
> > changes, because I wanted to exercise the code before I macro-ized it, but
> > I'm flexible.
>
> No, I'm in no hurry to go any further down this path. I don't think
> what is there already is worthwhile.
>
> We don't have better performance and we don't need the change in order
> to allow modules to implement their own bucket types.
I'm completely with Jeff on this one. I see no gains, and only negatives, in
this "improvement". Shrinking the bucket size buys us very little, and (as
Jeff says) the enumerated type is only important for us to write code to
detect a few, special types. Obviously, we couldn't have code to look for a
third-party type, so it doesn't matter what their bucket type is.
In fact, I'd formalize it and introduce AP_BUCKET_TYPE_EXTENSION. All
extensions to the bucket system can use that.
Ryan: will you back that change out?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Saturday, October 14, 2000 12:48 AM
>
> > I like the thought of being able to extend -what- filters
> can do, and
> > -how- they can do them. Extending into the vast unknown
> future bucket
> > types seems useful in ways we can't predict yet. I'm just
> making certain
> > that your performance issue is really the issue, or did we
> jam things up
> > somewhere else?
>
> Nobody is speaking against such an extension; I'm definitely for it.
> What I'm speaking about is more code in the path which we don't need.
Then that would be solved with the macros Ryan is offering up - I don't
disagree though that he wants to see the code work first.
here's what I think Ryan and I worked out...
the table is soley for reserving a numerical offset
the bucket itself will have a pointer straight to the bucket fn list
structure. The table lets us walk valid bucket types later on, but
not on a regular basis.
the fn ptr structure will include a char* bucketname
it won't be used often, but it will help in debugging and will be
the helper for a mod_dav_fs type module that -must- have an intimate
knowledge of bucket type installed by a mod_dav type parent module.
It can query by name against the table, but this would be done
once and cached for the life of the server.
the fn ptr structure will include a 'feature count' - number of
supported Apache bucket functions. We haven't worked that whole
thought out (who can define new fns - Apache core - mod authors?).
the fn ptr structures are 8 statics for the 8 core types, and they are
always in the enumeration's order.
all fn ptrs are initialized - worst is fn returning APR_NOTIMPL.
We have to test that the read/setaside/whatever actually succeeds,
so we drop a null ptr test for an extra error to be resolved
(the exception case instead of the rule).
Jeff - if a new bucket type queries apr -only once- for it's structure,
and gets it's assignment for the entire life of the server, and buckets
know their bucket type by a pointer to their fn ptrs structure, and you
can query the type of the bucket by name --- will that solve your issues?
RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Saturday, October 14, 2000 12:48 AM
> To: new-httpd@apache.org
> Subject: Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
>
> > I like the thought of being able to extend -what- filters can do, and
> > -how- they can do them. Extending into the vast unknown future bucket
> > types seems useful in ways we can't predict yet. I'm just making certain
> > that your performance issue is really the issue, or did we jam things up
> > somewhere else?
>
> Nobody is speaking against such an extension; I'm definitely for it.
> What I'm speaking about is more code in the path which we don't need.
Then I need to take a close look at the code we don't expect we need... can
I read the tree or did you last proposed patch overlay the behavior you
take issue with?
I've been a c++ com programmer for years - and I know many folks look at it
as wasteful - but if you are tight (we are) you shouldn't be wasting more
that a few cpu clicks with the double indirections. Now that I'm understanding
here what Ryan proposes - give me a little time to a close look at it before
we talk about backing it out ... I'm a little frustrated with all the talk in
the alpha of 'backing out' - we should be pushing forward and improving.
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> We've indirected the bucket object's vtble into it's own object. What's
> the issue here? Based on the cpu's cache and the frequency we hit these
> vtbls (see Roy's latest lecture), they should already land in cache.
> I guess I want to know what performace hit you are seeing, it can't
> simply be the indirection.
In this case, in-the-cache means not as much extra overhead as there
could be.
> I like the thought of being able to extend -what- filters can do, and
> -how- they can do them. Extending into the vast unknown future bucket
> types seems useful in ways we can't predict yet. I'm just making certain
> that your performance issue is really the issue, or did we jam things up
> somewhere else?
Nobody is speaking against such an extension; I'm definitely for it.
What I'm speaking about is more code in the path which we don't need.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Friday, October 13, 2000 2:25 PM
>
> rbb@covalent.net writes:
>
> > I had planned on letting this code work for a few days
> before making these
> > changes, because I wanted to exercise the code before I
> macro-ized it, but
> > I'm flexible.
>
> No, I'm in no hurry to go any further down this path. I don't think
> what is there already is worthwhile.
>
> We don't have better performance and we don't need the change in order
> to allow modules to implement their own bucket types.
Ok... I'm confused... time to play C++ programmer here...
We've indirected the bucket object's vtble into it's own object. What's
the issue here? Based on the cpu's cache and the frequency we hit these
vtbls (see Roy's latest lecture), they should already land in cache.
I guess I want to know what performace hit you are seeing, it can't
simply be the indirection.
I know I go overboard in trying to make things generic myself, but if
we follow this design in the direction we are heading, the filter
knows nothing of it's upstream and downstream neighbors, only what the
-current- request and requested results should be. So you know the
data -was- in utf-8, you know the client -wants- cp-850, and you happen
to be able to do that since you are a charset filter.
I like the thought of being able to extend -what- filters can do, and
-how- they can do them. Extending into the vast unknown future bucket
types seems useful in ways we can't predict yet. I'm just making certain
that your performance issue is really the issue, or did we jam things up
somewhere else?
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> I had planned on letting this code work for a few days before making these
> changes, because I wanted to exercise the code before I macro-ized it, but
> I'm flexible.
No, I'm in no hurry to go any further down this path. I don't think
what is there already is worthwhile.
We don't have better performance and we don't need the change in order
to allow modules to implement their own bucket types.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by rb...@covalent.net.
> I already miss the ability to print a bucket in gdb and have it tell
> me in words what the type of the bucket is.
This too can be fixed, by allowing people to add names to the bucket
types, and storing that with the bucket functions. If you would like, as
soon as I finish implementing the changes to ap_get_client_block that were
discussed yesterday, I will make this code use macros and structure
pointers instead of just an index. Then I will make gdb be able to tell
you what kind of bucket it is.
I had planned on letting this code work for a few days before making these
changes, because I wanted to exercise the code before I macro-ized it, but
I'm flexible.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> On 13 Oct 2000, Jeff Trawick wrote:
> > rbb@locus.apache.org writes:
> > > Log:
> > > Remove all function pointers from the ap_bucket type. These function
> > > pointers are replaced with a global table that allows modules to register
> > > their bucket types. Those bucket types are then allowed to be used in
> > > the server processing. This also required removing all direct calls to
> > > those functions. The ap_bucket type has an index into an array, so in
> > > each ap_bucket_* function, we use that index to find the correct set of
> > > functions.
> >
> > What is the purpose of this? We just got even slower.
>
> The purpose is to shrink the size of the buckets structure so that we
> allocate them faster.
When we use a pool of bucket structures, the cost of allocation will
be unrelated to the size of the bucket structure. I doubt that even
with the current allocation code the current shrinkage results in
faster allocation/deallocation, but that is irrelevant.
> This also divorces the bucket structure from the currently implemented
> bucket types, and makes it possible for people to extend the bucket
> types. Think of an SSL socket for input filtering. We can't use a
> standard socket_bucket, because that would use the wrong recv
> function.
So prior to this patch, if I'm mod_ssl and I create an instance of my
custom bucket type and pass it up, where is the baddness? I need to
make sure that the type doesn't collide with any core-provided types
(a simple ap_get-me-a-type() will take care of that). I need to
provide the proper read() and destroy() and split() functions.
> This has been documented as a necessary enhancement for some time in the
> header files, and doing now keeps us from using e->read or e->split or
> e->destroy, because they won't work at all anymore.
>
> I have already been asked by at least one other person for a way to
> implement their own bucket types that their module understands. This
> allows for that, the previous design didn't, because it used an enumerated
> type for bucket type.
The old mechanism can use enumerated values for core-provided bucket
types and use values above the max for bucket types which have to be
explicitly registered.
I already miss the ability to print a bucket in gdb and have it tell
me in words what the type of the bucket is.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by rb...@covalent.net.
On 13 Oct 2000, Jeff Trawick wrote:
> rbb@locus.apache.org writes:
> > Log:
> > Remove all function pointers from the ap_bucket type. These function
> > pointers are replaced with a global table that allows modules to register
> > their bucket types. Those bucket types are then allowed to be used in
> > the server processing. This also required removing all direct calls to
> > those functions. The ap_bucket type has an index into an array, so in
> > each ap_bucket_* function, we use that index to find the correct set of
> > functions.
>
> What is the purpose of this? We just got even slower.
The purpose is to shrink the size of the buckets structure so that we
allocate them faster. The problem right now as far as speed is concerned,
is that we are actually using an index into an array rather than a pointer
to another structure. The performance issue can be solved by 1), removing
the functions, and replacing them with macros. 2) using a pointer to a
structure rather than an index into an array.
This also divorces the bucket structure from the currently implemented
bucket types, and makes it possible for people to extend the bucket
types. Think of an SSL socket for input filtering. We can't use a
standard socket_bucket, because that would use the wrong recv function.
This has been documented as a necessary enhancement for some time in the
header files, and doing now keeps us from using e->read or e->split or
e->destroy, because they won't work at all anymore.
I have already been asked by at least one other person for a way to
implement their own bucket types that their module understands. This
allows for that, the previous design didn't, because it used an enumerated
type for bucket type.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@locus.apache.org writes:
> rbb 00/10/12 22:35:58
>
> Modified: src CHANGES
> src/ap ap_buckets.c ap_buckets_eos.c ap_buckets_file.c
> ap_buckets_heap.c ap_buckets_mmap.c
> ap_buckets_pipe.c ap_buckets_simple.c
> ap_buckets_socket.c
> src/include ap_buckets.h
> src/main http_core.c http_protocol.c util_filter.c
> src/modules/experimental mod_charset_lite.c
> src/modules/standard mod_include.c
> Log:
> Remove all function pointers from the ap_bucket type. These function
> pointers are replaced with a global table that allows modules to register
> their bucket types. Those bucket types are then allowed to be used in
> the server processing. This also required removing all direct calls to
> those functions. The ap_bucket type has an index into an array, so in
> each ap_bucket_* function, we use that index to find the correct set of
> functions.
What is the purpose of this? We just got even slower.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by rb...@covalent.net.
On 13 Oct 2000, Jeff Trawick wrote:
> rbb@locus.apache.org writes:
> > Remove all function pointers from the ap_bucket type. These function
> > pointers are replaced with a global table that allows modules to register
> > their bucket types. Those bucket types are then allowed to be used in
> > the server processing. This also required removing all direct calls to
> > those functions. The ap_bucket type has an index into an array, so in
> > each ap_bucket_* function, we use that index to find the correct set of
> > functions.
>
> So how do I see if the bucket in hand is an EOS bucket without making
> a function call? !@#$%^&*!~!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Right now, you can't. With a SMALL amount of work, make it a macro! Why
do you care about performance right now anyway? Apache has never been
overly concerned about performance, we make no claims to be the fastest
web server around.
A lot of our performance issues can be fixed by using macros and inlined
functions. Those are tweaks, and they can be done in beta. Right now,
using functions makes it a lot easier to debug things, and we haven't
really looked at where inlining would make sense.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@locus.apache.org writes:
> rbb 00/10/12 22:35:58
>
> Modified: src CHANGES
> src/ap ap_buckets.c ap_buckets_eos.c ap_buckets_file.c
> ap_buckets_heap.c ap_buckets_mmap.c
> ap_buckets_pipe.c ap_buckets_simple.c
> ap_buckets_socket.c
> src/include ap_buckets.h
> src/main http_core.c http_protocol.c util_filter.c
> src/modules/experimental mod_charset_lite.c
> src/modules/standard mod_include.c
> Log:
> Remove all function pointers from the ap_bucket type. These function
> pointers are replaced with a global table that allows modules to register
> their bucket types. Those bucket types are then allowed to be used in
> the server processing. This also required removing all direct calls to
> those functions. The ap_bucket type has an index into an array, so in
> each ap_bucket_* function, we use that index to find the correct set of
> functions.
So how do I see if the bucket in hand is an EOS bucket without making
a function call? !@#$%^&*!~!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Canonical names - what are they?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Based on my inability to edit the recipient of an email message
- tonight isn't the night I'm commiting code.
Here's a brain teaser for you all... what is a canonical file name?
Unix believes they are the given name. canonical(p,n) = n.
OS2 believes they aught to be absolute-pathed, Win32 doesn't.
I'm about to finish the port to apr of everything left over in os.h.
The os.h, os_inline.c and util_os.c all need to die now.
I'm not happy keeping 'canonical' as our identifier unless we agree
-what- it is, and -why-. I'm expecting we actually need several
different families:
make_abspath + is_abspath
make_relpath + is_relpath
these would always knock out redundant slashes, backdirs, thisdirs,
and the like, taking special precautions for things like win32 trailing
.'s and wildcards. I'm almost thinking of a single call that would
offer flags such as ALLOW_WILDCARDS, MATCH_TRUECASE and FORCE_TRUECASE.
It will also return a pointer where it stops parsing for resolution
of the things that didn't exist.
Whatever we do, we have to stop testing two, three, four times over
the same path name. Once a path is resolved, it should stay that way.
If noone has any feedback I'll be hacking this out over the next several
days. I'll identify all the goofy places that mod_include, mod_userdir
and others play filename games they shouldn't have to understand. I'll
put together the api and offer the patch to the actual Apache core and
modules, and then implement the apr for unix/win32/os2 - but it's up to
the platform folks to rip on it.
If you have feedback, complaints or suggestions please offer them up
before I invest the energy to pound this out.
Bill
RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ryan - call me back --- 847-265-8130
I'll tell you where you did wrong :-)
> -----Original Message-----
> From: rbb@locus.apache.org [mailto:rbb@locus.apache.org]
> Sent: Friday, October 13, 2000 12:36 AM
> To: apache-2.0-cvs@apache.org
> Subject: cvs commit: apache-2.0/src/modules/standard mod_include.c
>
>
> rbb 00/10/12 22:35:58
>
> Modified: src CHANGES
> src/ap ap_buckets.c ap_buckets_eos.c
> ap_buckets_file.c
> ap_buckets_heap.c ap_buckets_mmap.c
> ap_buckets_pipe.c ap_buckets_simple.c
> ap_buckets_socket.c
> src/include ap_buckets.h
> src/main http_core.c http_protocol.c util_filter.c
> src/modules/experimental mod_charset_lite.c
> src/modules/standard mod_include.c
> Log:
> Remove all function pointers from the ap_bucket type.
> These function
> pointers are replaced with a global table that allows
> modules to register
> their bucket types. Those bucket types are then allowed to
> be used in
> the server processing. This also required removing all
> direct calls to
> those functions. The ap_bucket type has an index into an
> array, so in
> each ap_bucket_* function, we use that index to find the
> correct set of
> functions.
>
> Revision Changes Path
> 1.272 +5 -0 apache-2.0/src/CHANGES
>
> Index: CHANGES
> ===================================================================
> RCS file: /home/cvs/apache-2.0/src/CHANGES,v
> retrieving revision 1.271
> retrieving revision 1.272
> diff -u -r1.271 -r1.272
> --- CHANGES 2000/10/13 03:38:34 1.271
> +++ CHANGES 2000/10/13 05:35:52 1.272
> @@ -1,4 +1,9 @@
> Changes with Apache 2.0a8
> + *) Remove the function pointers from the ap_bucket type.
> They have been
> + replaced with a global table. Modules are allowed to
> register bucket
> + types and use then use those buckets.
> + [Ryan Bloom]
> +
> *) mod_cgid: In the handler, shut down the Unix socket
> (only for write)
> once we finish writing the request body to the cgi
> child process;
> otherwise, the client doesn't hit EOF on stdin.
> Small request bodies
>