EAPI = bloatware ? Of I'm just confused ...
After look on EAPI I'm could not understood why it's designed to be so bloat
and slow. Why other (MUCH more simpler) design is unacceptable:
#define hook_define(hook_name,hook_signature,hook_params) \
extern struct hook_struct_##hook_name { \
int (hook_addr)hook_signature; \
struct hook_struct##hook_name* next; \
} *hook_start_##hook_name; \
static __inline__ int hook_call_##hook_name(hook_signature) { \
hook_struct_##hook_name *p=&hook_start_##hook_name; \
while (p) { \
if (p->hook_addr hook_params ) return 1; \
p=p->next; \
} \
}
Then you'll use this all like
hook_define(Great_hook,(char x,void ** y,int(z)(char,int)),(x,y,z))
in .h file (to be included in both "client" module and "server" module) and
hook_register(Great_hook) in the initialization of client_module plus
hook_enable(Great_hook) in the initialization of server_module. Then all
hook calls (hook_call_Great_hook('a',&p,f) :-) will be just few comparisions
instead of lookup in string table. 10-15 times faster when simple hook is used
(almost the same speed as simple function call!) and 100+ times faster when
hooks are not used. Of course current approach is acceptable for mod_ssl
(encryption is slow by itself) but it's not acceptable as generic hook
mechanism (IMO, anyway). And even for mod_ssl it's not so good since this will
slow down non-SSL server as well. Or I'm misunderstood something ?
P.S. Of course this is only schematic description -- you'll need pool to keep
track of pools, etc. But with current approach when there are will be a lot of
hooks each and every rputc will lead to lookup in big string table ! Clearly
unappropriate IMO :-((
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
