You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/10/11 09:50:06 UTC
[patch 2.0] hook linkage, take 2
After mulling over the many comments, and my own frustration
that I saw this coming, here is my -bare- -minimum- patch that
can let us be flexible without getting carried away.
The ap_config patch adds MODULE_EXPORT(type) to declare a function
with the stated return type. This follows the behavior of the
MODULE_VAR_EXPORT symbol, and means 'always export me'. It can
never be used in a header, but it is welcome in a .c source.
The ap_hooks patch is amusing. IMPLEMENT_HOOK_any is always used
in the .c source, so changing them all to MODULE_EXPORT resolves
this problem. The remaining issue (with mod_dav.h, especially) is
the DECLARE_HOOK. Everybody went bonkers when we added args here.
So I'm suggesting one arg, and not even a full one at that.
We will assume all linkage specs end in _VAR_EXPORT, _EXPORT or
_EXPORT_NONSTD. Therefore, the first arg of IMPLEMENT_HOOK becomes
the prefix, alone. In the core, this is simply API. In mod_dav,
it's DAV (_EXPORT() etc.)
Please tell me if this is legible enough to live with, so we can
proceed. I have the full patch to enable DAV waiting to commit.
the mod_dav.h sample follows at the end of this patch.
Bill
Index: include/ap_config.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_config.h,v
retrieving revision 1.41
diff -u -r1.41 ap_config.h
--- include/ap_config.h 2000/08/06 06:07:01 1.41
+++ include/ap_config.h 2000/10/11 07:28:23
@@ -70,21 +70,25 @@
#define API_EXPORT(type) type
#define API_EXPORT_NONSTD(type) type
#define API_VAR_EXPORT
+#define MODULE_EXPORT(type) type
#define MODULE_VAR_EXPORT
#elif defined(API_STATIC)
#define API_EXPORT(type) type __stdcall
#define API_EXPORT_NONSTD(type) type
#define API_VAR_EXPORT
+#define MODULE_EXPORT(type) type __stdcall
#define MODULE_VAR_EXPORT
#elif defined(API_EXPORT_SYMBOLS)
#define API_EXPORT(type) __declspec(dllexport) type __stdcall
#define API_EXPORT_NONSTD(type) __declspec(dllexport) type
#define API_VAR_EXPORT __declspec(dllexport)
+#define MODULE_EXPORT(type) __declspec(dllexport) type __stdcall
#define MODULE_VAR_EXPORT __declspec(dllexport)
#else
#define API_EXPORT(type) __declspec(dllimport) type __stdcall
#define API_EXPORT_NONSTD(type) __declspec(dllimport) type
#define API_VAR_EXPORT __declspec(dllimport)
+#define MODULE_EXPORT(type) __declspec(dllexport) type __stdcall
#define MODULE_VAR_EXPORT __declspec(dllexport)
#endif
Index: include/ap_hooks.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_hooks.h,v
retrieving revision 1.22
diff -u -r1.22 ap_hooks.h
--- include/ap_hooks.h 2000/08/02 05:25:26 1.22
+++ include/ap_hooks.h 2000/10/11 07:28:23
@@ -64,11 +64,11 @@
* @package Apache hooks functions
*/
-#define AP_DECLARE_HOOK(ret,name,args) \
+#define AP_DECLARE_HOOK(link,ret,name,args) \
typedef ret HOOK_##name args; \
-API_EXPORT(void) ap_hook_##name(HOOK_##name *pf,const char * const *aszPre, \
+link##_EXPORT(void) ap_hook_##name(HOOK_##name *pf,const char * const *aszPre, \
const char * const *aszSucc,int nOrder); \
-API_EXPORT(ret) ap_run_##name args; \
+link##_EXPORT(ret) ap_run_##name args; \
typedef struct _LINK_##name \
{ \
HOOK_##name *pFunc; \
@@ -85,8 +85,8 @@
apr_array_header_t *link_##name;
#define AP_IMPLEMENT_HOOK_BASE(name) \
-API_EXPORT(void) ap_hook_##name(HOOK_##name *pf,const char * const *aszPre, \
- const char * const *aszSucc,int nOrder) \
+MODULE_EXPORT(void) ap_hook_##name(HOOK_##name *pf,const char * const *aszPre, \
+ const char * const *aszSucc,int nOrder) \
{ \
LINK_##name *pHook; \
if(!_hooks.link_##name) \
@@ -111,7 +111,7 @@
#define AP_IMPLEMENT_HOOK_VOID(name,args_decl,args_use) \
AP_IMPLEMENT_HOOK_BASE(name) \
-API_EXPORT(void) ap_run_##name args_decl \
+MODULE_EXPORT(void) ap_run_##name args_decl \
{ \
LINK_##name *pHook; \
int n; \
@@ -129,7 +129,7 @@
*/
#define AP_IMPLEMENT_HOOK_RUN_ALL(ret,name,args_decl,args_use,ok,decline) \
AP_IMPLEMENT_HOOK_BASE(name) \
-API_EXPORT(ret) ap_run_##name args_decl \
+MODULE_EXPORT(ret) ap_run_##name args_decl \
{ \
LINK_##name *pHook; \
int n; \
@@ -151,7 +151,7 @@
#define AP_IMPLEMENT_HOOK_RUN_FIRST(ret,name,args_decl,args_use,decline) \
AP_IMPLEMENT_HOOK_BASE(name) \
-API_EXPORT(ret) ap_run_##name args_decl \
+MODULE_EXPORT(ret) ap_run_##name args_decl \
{ \
LINK_##name *pHook; \
int n; \
Index: include/ap_cache.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_cache.h,v
retrieving revision 1.8
diff -u -r1.8 ap_cache.h
--- include/ap_cache.h 2000/09/10 20:45:16 1.8
+++ include/ap_cache.h 2000/10/11 07:28:23
@@ -331,7 +331,7 @@
* passed into ap_cache_init. If your cache wants to reject a hook call return
* APR_ENOTIMPL from your hook and the next caching module will be tried.
*/
-AP_DECLARE_HOOK(apr_status_t, cache_init, (ap_cache_handle_t **, const char *desc, server_rec *t))
+AP_DECLARE_HOOK(API, apr_status_t, cache_init, (ap_cache_handle_t **, const char *desc, server_rec *t))
/* These are various enum's passed into call back functions (as defined below) */
typedef enum { AP_CACHE_SEEK, AP_CACHE_CREATE, AP_CACHE_CHANGE, AP_CACHE_REMOVE } ap_cache_query;
Index: include/http_config.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/http_config.h,v
retrieving revision 1.49
diff -u -r1.49 http_config.h
--- include/http_config.h 2000/09/13 01:58:13 1.49
+++ include/http_config.h 2000/10/11 07:28:23
@@ -962,7 +962,7 @@
* @return OK or DECLINED
* @deffunc int ap_run_header_parser(request_rec *r)
*/
-AP_DECLARE_HOOK(int,header_parser,(request_rec *))
+AP_DECLARE_HOOK(API,int,header_parser,(request_rec *))
/**
* Run the pre_config function for each module
@@ -971,7 +971,7 @@
* @param ptemp The temporary pool
* @deffunc void ap_run_pre_config(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp)
*/
-AP_DECLARE_HOOK(void,pre_config,
+AP_DECLARE_HOOK(API,void,pre_config,
(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp))
/**
@@ -982,7 +982,7 @@
* @param s The list of server_recs
* @deffunc void ap_run_post_config(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp, server_rec *s)
*/
-AP_DECLARE_HOOK(void,post_config,
+AP_DECLARE_HOOK(API,void,post_config,
(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp,server_rec *s))
/**
@@ -993,7 +993,7 @@
* @param s The list of server_recs
* @deffunc void ap_run_open_logs(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp, server_rec *s)
*/
-AP_DECLARE_HOOK(void,open_logs,
+AP_DECLARE_HOOK(API,void,open_logs,
(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t *ptemp,server_rec *s))
/**
@@ -1002,7 +1002,7 @@
* @param s The list of server_recs in this server
* @deffunc void ap_run_child_init(apr_pool_t *pchild, server_rec *s)
*/
-AP_DECLARE_HOOK(void,child_init,(apr_pool_t *pchild, server_rec *s))
+AP_DECLARE_HOOK(API,void,child_init,(apr_pool_t *pchild, server_rec *s))
#ifdef __cplusplus
}
Index: include/http_connection.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/http_connection.h,v
retrieving revision 1.23
diff -u -r1.23 http_connection.h
--- include/http_connection.h 2000/10/02 19:52:33 1.23
+++ include/http_connection.h 2000/10/11 07:28:24
@@ -142,7 +142,7 @@
* @return OK or DECLINED
* @deffunc int ap_run_pre_connection(conn_rec *c)
*/
-AP_DECLARE_HOOK(int,pre_connection,(conn_rec *))
+AP_DECLARE_HOOK(API,int,pre_connection,(conn_rec *))
/**
* This hook implements different protocols. After a connection has been
@@ -153,7 +153,7 @@
* @return OK or DECLINED
* @deffunc int ap_run_process_connection(conn_rec *c)
*/
-AP_DECLARE_HOOK(int,process_connection,(conn_rec *))
+AP_DECLARE_HOOK(API,int,process_connection,(conn_rec *))
#ifdef __cplusplus
}
Index: include/http_protocol.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/http_protocol.h,v
retrieving revision 1.27
diff -u -r1.27 http_protocol.h
--- include/http_protocol.h 2000/10/08 00:55:46 1.27
+++ include/http_protocol.h 2000/10/11 07:28:24
@@ -544,7 +544,7 @@
* @return OK or DECLINED
* @deffunc ap_run_post_read_request(request_rec *r)
*/
-AP_DECLARE_HOOK(int,post_read_request,(request_rec *))
+AP_DECLARE_HOOK(API,int,post_read_request,(request_rec *))
/**
* This hook allows modules to perform any module-specific logging activities
* over and above the normal server things.
@@ -552,7 +552,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_log_transaction(request_rec *r)
*/
-AP_DECLARE_HOOK(int,log_transaction,(request_rec *))
+AP_DECLARE_HOOK(API,int,log_transaction,(request_rec *))
/**
* This hook allows modules to retrieve the http method from a request. This
* allows Apache modules to easily extend the methods that Apache understands
@@ -560,14 +560,14 @@
* @return The http method from the request
* @deffunc const char *ap_run_http_method(const request_rec *r)
*/
-AP_DECLARE_HOOK(const char *,http_method,(const request_rec *))
+AP_DECLARE_HOOK(API,const char *,http_method,(const request_rec *))
/**
* Return the default port from the current request
* @param r The current request
* @return The current port
* @deffunc unsigned short ap_run_default_port(const request_rec *r)
*/
-AP_DECLARE_HOOK(unsigned short,default_port,(const request_rec *))
+AP_DECLARE_HOOK(API,unsigned short,default_port,(const request_rec *))
#ifdef __cplusplus
}
Index: include/http_request.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/http_request.h,v
retrieving revision 1.16
diff -u -r1.16 http_request.h
--- include/http_request.h 2000/08/14 02:36:42 1.16
+++ include/http_request.h 2000/10/11 07:28:24
@@ -229,7 +229,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_translate_name(request_rec *r)
*/
-AP_DECLARE_HOOK(int,translate_name,(request_rec *))
+AP_DECLARE_HOOK(API,int,translate_name,(request_rec *))
/**
* This hook allows modules to check the authentication information sent with
@@ -238,7 +238,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_check_user_id(request_rec *r)
*/
-AP_DECLARE_HOOK(int,check_user_id,(request_rec *))
+AP_DECLARE_HOOK(API,int,check_user_id,(request_rec *))
/**
* Allows modules to perform module-specific fixing of header fields. This
@@ -247,7 +247,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_fixups(request_rec *r)
*/
-AP_DECLARE_HOOK(int,fixups,(request_rec *))
+AP_DECLARE_HOOK(API,int,fixups,(request_rec *))
/**
* This routine is called to determine and/or set the various document type
@@ -257,7 +257,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_type_checker(request_rec *r)
*/
-AP_DECLARE_HOOK(int,type_checker,(request_rec *))
+AP_DECLARE_HOOK(API,int,type_checker,(request_rec *))
/**
* This routine is called to check for any module-specific restrictions placed
@@ -266,7 +266,7 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_access_checker(request_rec *r)
*/
-AP_DECLARE_HOOK(int,access_checker,(request_rec *))
+AP_DECLARE_HOOK(API,int,access_checker,(request_rec *))
/**
* This routine is called to check to see if the resource being requested
@@ -275,14 +275,14 @@
* @return OK, DECLINED, or HTTP_...
* @deffunc int ap_run_auth_checker(request_rec *r)
*/
-AP_DECLARE_HOOK(int,auth_checker,(request_rec *))
+AP_DECLARE_HOOK(API,int,auth_checker,(request_rec *))
/**
* This hook allows modules to insert filters for the current request
* @param r the current request
* @deffunc void ap_run_insert_filter(request_rec *r)
*/
-AP_DECLARE_HOOK(void,insert_filter,(request_rec *))
+AP_DECLARE_HOOK(API,void,insert_filter,(request_rec *))
#ifdef __cplusplus
}
How this affects mod_dav.h (sources ommitted for brevity):
Index: modules/dav/main/mod_dav.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/modules/dav/main/mod_dav.h,v
retrieving revision 1.20
diff -u -r1.20 mod_dav.h
--- modules/dav/main/mod_dav.h 2000/10/10 11:42:22 1.20
+++ modules/dav/main/mod_dav.h 2000/10/11 07:28:36
@@ -105,6 +105,19 @@
#define DAV_INFINITY INT_MAX /* for the Depth: header */
+/* These declarations simply mimic the core declarations. On Win32
+ * the DAV_EXPORT_SYMBOLS define at compile time will cause all
+ * DAV_EXPORT()s to export. If the symbol is not defined at compile
+ * time this header uses import declarations. DAV does not expect
+ * to be imported from the core, so the API_EXPORT symbol is safe.
+ */
+#ifndef WIN32
+#define DAV_EXPORT(type) type
+#elif defined(DAV_EXPORT_SYMBOLS)
+#define DAV_EXPORT(type) MODULE_EXPORT(type)
+#else
+#define DAV_EXPORT(type) API_EXPORT(type)
+#endif
/* --------------------------------------------------------------------
**
@@ -146,7 +159,8 @@
** Create a new error structure. save_errno will be filled with the current
** errno value.
*/
-dav_error *dav_new_error(apr_pool_t *p, int status, int error_id, const char *desc);
+DAV_EXPORT(dav_error*) dav_new_error(apr_pool_t *p, int status,
+ int error_id, const char *desc);
/*
** Push a new error description onto the stack of errors.
@@ -161,8 +175,8 @@
** <error_id> can specify a new error_id since the topmost description has
** changed.
*/
-dav_error *dav_push_error(apr_pool_t *p, int status, int error_id, const char *desc,
- dav_error *prev);
+DAV_EXPORT(dav_error*) dav_push_error(apr_pool_t *p, int status, int error_id,
+ const char *desc, dav_error *prev);
/* error ID values... */
@@ -339,23 +353,28 @@
#define DAV_BUFFER_PAD 64 /* amount of pad when growing */
/* set the cur_len to the given size and ensure space is available */
-void dav_set_bufsize(apr_pool_t *p, dav_buffer *pbuf, apr_size_t size);
+DAV_EXPORT(void) dav_set_bufsize(apr_pool_t *p, dav_buffer *pbuf,
+ apr_size_t size);
/* initialize a buffer and copy the specified (null-term'd) string into it */
-void dav_buffer_init(apr_pool_t *p, dav_buffer *pbuf, const char *str);
+DAV_EXPORT(void) dav_buffer_init(apr_pool_t *p, dav_buffer *pbuf, const char *str);
/* check that the buffer can accomodate <extra_needed> more bytes */
-void dav_check_bufsize(apr_pool_t *p, dav_buffer *pbuf, apr_size_t extra_needed);
+DAV_EXPORT(void) dav_check_bufsize(apr_pool_t *p, dav_buffer *pbuf,
+ apr_size_t extra_needed);
/* append a string to the end of the buffer, adjust length */
-void dav_buffer_append(apr_pool_t *p, dav_buffer *pbuf, const char *str);
+DAV_EXPORT(void) dav_buffer_append(apr_pool_t *p, dav_buffer *pbuf,
+ const char *str);
/* place a string on the end of the buffer, do NOT adjust length */
-void dav_buffer_place(apr_pool_t *p, dav_buffer *pbuf, const char *str);
+DAV_EXPORT(void) dav_buffer_place(apr_pool_t *p, dav_buffer *pbuf,
+ const char *str);
/* place some memory on the end of a buffer; do NOT adjust length */
-void dav_buffer_place_mem(apr_pool_t *p, dav_buffer *pbuf, const void *mem,
- apr_size_t amt, apr_size_t pad);
+DAV_EXPORT(void) dav_buffer_place_mem(apr_pool_t *p, dav_buffer *pbuf,
+ const void *mem, apr_size_t amt,
+ apr_size_t pad);
/* --------------------------------------------------------------------
@@ -432,14 +451,14 @@
} dav_provider;
-AP_DECLARE_HOOK(void, gather_propsets, (apr_array_header_t *uris))
-AP_DECLARE_HOOK(int, find_liveprop, (request_rec *r,
- const char *ns_uri, const char *name,
- const dav_hooks_liveprop **hooks))
-AP_DECLARE_HOOK(void, insert_all_liveprops, (request_rec *r,
- const dav_resource *resource,
- int insvalue,
- ap_text_header *phdr))
+AP_DECLARE_HOOK(DAV, void, gather_propsets, (apr_array_header_t *uris))
+AP_DECLARE_HOOK(DAV, int, find_liveprop, (request_rec *r,
+ const char *ns_uri, const char *name,
+ const dav_hooks_liveprop **hooks))
+AP_DECLARE_HOOK(DAV, void, insert_all_liveprops, (request_rec *r,
+ const dav_resource *resource,
+ int insvalue,
+ ap_text_header *phdr))
/* ### make this internal to mod_dav.c ? */
#define DAV_KEY_RESOURCE "dav-resource"
@@ -448,12 +467,13 @@
const dav_hooks_propdb *dav_get_propdb_hooks(request_rec *r);
const dav_hooks_vsn *dav_get_vsn_hooks(request_rec *r);
-void dav_register_provider(apr_pool_t *p, const char *name,
- const dav_provider *hooks);
+DAV_EXPORT(void) dav_register_provider(apr_pool_t *p, const char *name,
+ const dav_provider *hooks);
const dav_provider * dav_lookup_provider(const char *name);
-void dav_register_liveprop_namespace(apr_pool_t *pool, const char *uri);
-int dav_get_liveprop_ns_index(const char *uri);
+DAV_EXPORT(void) dav_register_liveprop_namespace(apr_pool_t *pool,
+ const char *uri);
+DAV_EXPORT(int) dav_get_liveprop_ns_index(const char *uri);
int dav_get_liveprop_ns_count(void);
void dav_add_all_liveprop_xmlns(apr_pool_t *p, ap_text_header *phdr);
@@ -865,8 +885,9 @@
int resource_state,
int depth);
-dav_error * dav_lock_query(dav_lockdb *lockdb, const dav_resource *resource,
- dav_lock **locks);
+DAV_EXPORT(dav_error*) dav_lock_query(dav_lockdb *lockdb,
+ const dav_resource *resource,
+ dav_lock **locks);
dav_error * dav_validate_request(request_rec *r, dav_resource *resource,
int depth, dav_locktoken *locktoken,
@@ -1248,8 +1269,8 @@
} dav_walker_ctx;
-void dav_add_response(dav_walker_ctx *ctx, const char *href, int status,
- dav_get_props_result *propstats);
+DAV_EXPORT(void) dav_add_response(dav_walker_ctx *ctx, const char *href,
+ int status, dav_get_props_result *propstats);
/* --------------------------------------------------------------------
Re: Apache 2.0 on multiproc vs single proc
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Sure, go for it :-) Let us know if you find anything interesting.
Greg
Austin Gonyou wrote:
>
> Well,
> I'm planning to do that benchmarking. And as such, I wanted to know if
> I should even persist with wanting to, if it was an easy answer.
> Austin
>
Re: Apache 2.0 on multiproc vs single proc
Posted by Austin Gonyou <au...@coremetrics.com>.
Well,
I'm planning to do that benchmarking. And as such, I wanted to know if
I should even persist with wanting to, if it was an easy answer.
Austin
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10/11/00, 1:58:45 PM, Greg Ames <gr...@raleigh.ibm.com> wrote
regarding Re: Apache 2.0 on multiproc vs single proc:
> Austin,
> I believe your choice of OS is going to make more of a difference on
> your Web server's ability to scale with multiple processors than Apache
> will. I'm thinking here of the serialization (locking) in TCP/IP in the
> Linux kernels prior to 2.4. I've heard second hand that BSD is better
> than Linux < 2.4 with respect to SMP scalability when you get up to
> around 4 processors. But with two processors it shouldn't be a big deal
> either way. A dual processor board with 2 500Mhz CPUs is probably more
> MIPs per buck than a single 1Ghz board + CPU.
> We added additional serialization in the Apache 2.0 threaded MPMs to
> make certain operations thread safe. I don't think anybody has done any
> serious benchmarking to see how this new stuff in Apache 2.0 affects SMP
> scalability.
> Greg
> Austin Gonyou wrote:
> >
> > Any info on single vs dual procs? I mainly want to know if it's a path
> > that I should pursue.
> >
> > Austin
Re: Apache 2.0 on multiproc vs single proc
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Austin,
I believe your choice of OS is going to make more of a difference on
your Web server's ability to scale with multiple processors than Apache
will. I'm thinking here of the serialization (locking) in TCP/IP in the
Linux kernels prior to 2.4. I've heard second hand that BSD is better
than Linux < 2.4 with respect to SMP scalability when you get up to
around 4 processors. But with two processors it shouldn't be a big deal
either way. A dual processor board with 2 500Mhz CPUs is probably more
MIPs per buck than a single 1Ghz board + CPU.
We added additional serialization in the Apache 2.0 threaded MPMs to
make certain operations thread safe. I don't think anybody has done any
serious benchmarking to see how this new stuff in Apache 2.0 affects SMP
scalability.
Greg
Austin Gonyou wrote:
>
> Any info on single vs dual procs? I mainly want to know if it's a path
> that I should pursue.
>
> Austin
Re: Apache 2.0 on multiproc vs single proc
Posted by Austin Gonyou <au...@coremetrics.com>.
Any info on single vs dual procs? I mainly want to know if it's a path
that I should pursue.
Austin
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10/11/00, 10:10:34 AM, <rb...@covalent.net> wrote regarding Re: Apache 2.0
on multiproc vs single proc:
> On Wed, 11 Oct 2000, Austin Gonyou wrote:
> > I'm trying to cost analysis for staying with dual procs vs single proc,
> > and in my initial testing, it seems to me that a single running threading
> > in apache 2.0 will have limited capacity vs dual procs. Can anyone on
> > this list shed some light? Also, does anyone know about ssl in apache
> > 2.0? No mod_ssl's seem to work with it.
> There are currently no mod_ssl's written for 2.0. I expect that since
the
> API is finally calming down a bit (except for input filtering) that
people
> will start to write ssl modules soon.
> Ryan
>
_______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
>
-------------------------------------------------------------------------------
Re: Apache 2.0 on multiproc vs single proc
Posted by rb...@covalent.net.
On Wed, 11 Oct 2000, Austin Gonyou wrote:
> I'm trying to cost analysis for staying with dual procs vs single proc,
> and in my initial testing, it seems to me that a single running threading
> in apache 2.0 will have limited capacity vs dual procs. Can anyone on
> this list shed some light? Also, does anyone know about ssl in apache
> 2.0? No mod_ssl's seem to work with it.
There are currently no mod_ssl's written for 2.0. I expect that since the
API is finally calming down a bit (except for input filtering) that people
will start to write ssl modules soon.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Apache 2.0 on multiproc vs single proc
Posted by Austin Gonyou <au...@coremetrics.com>.
I'm trying to cost analysis for staying with dual procs vs single proc,
and in my initial testing, it seems to me that a single running threading
in apache 2.0 will have limited capacity vs dual procs. Can anyone on
this list shed some light? Also, does anyone know about ssl in apache
2.0? No mod_ssl's seem to work with it.
Austin
RE: [patch 2.0] hook linkage, take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, October 11, 2000 3:46 AM
>
> Ah. I missed it the first time, and almost missed it this time. The
> dllexport vs dllimport thang. Blarg. That isn't clear.
>
> How about this: (with appropriate grandfathering)
>
> AP_DECLARE(type) /* or maybe AP_DECL */
> AP_DECLARE_NONSTD(type)
> AP_DECLARE_VAR
> AP_IMPL(type) /* maybe AP_DEFINE / AP_DEFN, but that's
> a bit too */
> AP_IMPL_VAR /* close to AP_DECLARE / AP_DECL */
>
> The above would be a bit more obvious what is going on.
>
> And to be clear: only Apache needs to use these, right? Third
> party modules would never use the above macros?
> [ although they would use a variant to export syms to other
> modules, such as mod_dav's needs ]
Ok... what if a bit of magic was used to declare entire matching sets.
If I can nest the macro declaration... one macro would declare the macros
of all three flavors...
_DECLARE_VAR prefixes a data declaration
_DECLARE_NONSTD(type) fn() is a portable (potentially pascal)
non-varargs compatible fn.
_DECLARE(type) fn() harry c (e.g. varargs) incompatable fn
for all platforms and compiler symbol tests with the simple syntax:
AP_LINKAGE_DECLARATION(prefix)
On to prefixes:
EXPORT_ just what it says
APR_ our favorite portability dll
AP_ our favorite core server dll
DAV_ modules, such as DAV_ would get their own symbol set out of
calling a single macro to set things up.
Would this make things cleaner? [The reason AP_ was not used for the core
in the first place was this lingering ap library. It looks like it will
rear it's head again. Can we do so with a clean, new name e.g. APF, if it
will be an external library?]
I'm going on with the first issue, the patch at hand. Feel free to debate
this a while, although I will proceed to build that macro now.
RE: [patch 2.0] hook linkage, take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Wednesday, October 11, 2000 3:46 AM
>
> On Wed, Oct 11, 2000 at 02:50:06AM -0500, William A. Rowe, Jr. wrote:
> > After mulling over the many comments, and my own frustration
> > that I saw this coming,
>
> We *knew* it was coming, but I don't think your solution at the time, nor
> the one below is "as good as it can be". Everybody pays the price for what
> some goofy module over in the corner does.
At the time someone could have concurred with the fn, and instructed me to
implement the -original- symbols in terms of the new, and skip changes to
the other modules. Now I understand your thoughts here, it will be committed
within the hour.
> *) add AP_DECLARE_LINKAGE_HOOK(link,ret,name,args) as you have below
> *) redefine AP_DECLARE_HOOK() in terms of above
> *) use AP_DECLARE_LINKAGE_HOOK() in mod_dav.h (or define a DAV_DECLARE_HOOK
> that does the right magic and use that)
I'm inclined to use AP_DECLARE_EXTERNAL_HOOK(link, , ,) implying that it
resides outside the core. Acceptable?
Re: [patch 2.0] hook linkage, take 2
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Oct 11, 2000 at 02:50:06AM -0500, William A. Rowe, Jr. wrote:
> After mulling over the many comments, and my own frustration
> that I saw this coming,
We *knew* it was coming, but I don't think your solution at the time, nor
the one below is "as good as it can be". Everybody pays the price for what
some goofy module over in the corner does.
*) add AP_DECLARE_LINKAGE_HOOK(link,ret,name,args) as you have below
*) redefine AP_DECLARE_HOOK() in terms of above
*) use AP_DECLARE_LINKAGE_HOOK() in mod_dav.h (or define a DAV_DECLARE_HOOK
that does the right magic and use that)
>...
> The ap_config patch adds MODULE_EXPORT(type) to declare a function
> with the stated return type. This follows the behavior of the
> MODULE_VAR_EXPORT symbol, and means 'always export me'. It can
> never be used in a header, but it is welcome in a .c source.
See my previous note. Why do we need both MODULE_* and API_* ? The contents
are the same between them.
Ah. I missed it the first time, and almost missed it this time. The
dllexport vs dllimport thang. Blarg. That isn't clear.
How about this: (with appropriate grandfathering)
AP_DECLARE(type) /* or maybe AP_DECL */
AP_DECLARE_NONSTD(type)
AP_DECLARE_VAR
AP_IMPL(type) /* maybe AP_DEFINE / AP_DEFN, but that's a bit too */
AP_IMPL_VAR /* close to AP_DECLARE / AP_DECL */
The above would be a bit more obvious what is going on.
And to be clear: only Apache needs to use these, right? Third party modules
would never use the above macros?
[ although they would use a variant to export syms to other modules, such as
mod_dav's needs ]
> The ap_hooks patch is amusing. IMPLEMENT_HOOK_any is always used
> in the .c source, so changing them all to MODULE_EXPORT resolves
> this problem. The remaining issue (with mod_dav.h, especially) is
> the DECLARE_HOOK. Everybody went bonkers when we added args here.
> So I'm suggesting one arg, and not even a full one at that.
See above. You're making everybody pay just because mod_dav declares a hook.
Keep it the same for everybody, and make mod_dav pay for its injustice. :-)
> We will assume all linkage specs end in _VAR_EXPORT, _EXPORT or
> _EXPORT_NONSTD. Therefore, the first arg of IMPLEMENT_HOOK becomes
> the prefix, alone. In the core, this is simply API. In mod_dav,
> it's DAV (_EXPORT() etc.)
>
> Please tell me if this is legible enough to live with, so we can
> proceed. I have the full patch to enable DAV waiting to commit.
> the mod_dav.h sample follows at the end of this patch.
Let's not monkey with the extra AP_DECLARE_HOOK arg. Keep it simple for the
majority.
For the other parts, I think we could reach some add'l clarity.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/