On Sun, Nov 08, 1998, Khimenko Victor wrote:
> EAPI = bloatware ? Of I'm just confused ...
<grin> Not intentionally bloatware, of course. More the result of trying to
combine three major requirements: portability (full ANSI C compliant),
functionality (works with the ugly Apache API restrictions and pitfalls) and
minimum API (to reduce the source patching to a minimum and provide a
intuitive ap_hook_xx interface).
So the current design is more the result of trying to integrate the
requirements. But perhaps I've integrated it too complex. This can be the
case, of course. Here you can help me to simplify it now...
> 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 :-((
Correct, Martin Kraemer and I already recognized that the string comparisons
can be too slow (although regarding Deans performance statements on the
non-optimized ap_table_xxx stuff the performance penalty for
string-comparisons is not such noticeable as one might expect. The real
performance problems is I/O in Apache).
But we can for instance optimize the EAPI stuff to use numeric IDs through a
hash-table instead of strings as the unique identifiers. So, you're right
that we can optimize EAPI a lot. But this doesn't mean we also can replace it
directly with your non-bloated inline-approach, IMHO. These are two totally
different things.
Let me explain the design behind the EAPI stuff a little bit: I've thought
about a pre-processing based approach first, of course. Because this way I
could avoid the encoding and dispatching over the various function signatures
(the only thing which restricts the ap_hook stuff). But as you already noticed
your approach is still only schematic and when you think deeper you recognize
that pool handling, various signature handling, the context variable handling
etc. gets such complex that you cannot do it via the pre-processor approach.
I've though really very long three weeks ago about this stuff but was never
able to incorporate _all_ needed functionality under the hat of a
pre-processor based approach.
Because the current design directly follows the requirements. I've first added
the hooks to buff.c, mod_log_config.c and proxy_http.c, etc. and then tried
to implement them. But it was really horrible to get such a generic mechanism
working. Because there are very subtle problems which crazy call-variants like
ap_hook_use() solve. For instance we cannot make an assumption whether a hook
is really configured before functions are registered because of the Apache API
control flow and module ordering. Then there are other problems: For instance
I wanted to max reduce the patches and make the ap_hook_xxx() API very clean
and intuitive. Here the only solution to overcome the various argument type
and compiler restrictions is to use var-args (unions doesn't work here). But
in order to use them you need to know the function signatures, etc. This
leaded to the idea to encode them into a bit-field, etc. Then there is the
problem that the return value of a hook function can have totally different
semantics. That's for what AP_HOOK_DECLINE() exists, etc.
In one sentence: I've tried really a lot of variants and the current approach
is a first (although still non-optimized) cut for a _working_ solution which
is really portable and ANSI C compliant but still provides both the required
functionality and the wished ap_hook_xxx() API. When you really find a
pre-processor based approach which provides the same, I'm more than happy to
give it a try. But sorry to say this, I think you will hate to work on it and
perhaps finally fail. Because portability and functionality is really hard to
combine here.
So, I would appreciate to concentrate now on only _optimizing_ the existing
ap_hook_call() and ap_hook_use() functions instead of finding a totally
different alternative approach. Because I'm 95% sure the current approach is a
very portable one (and portability is more important than speed here, of
course). I really want to avoid finding again an alternative implementation -
it's a horrible complex and very time-consuming task. According to my
working-hour sheet for the mod_ssl project I already spent around 60-80
working hours to find the current solution, so please understand that I'm not
very keen to again find one myself. When you contribute one which also works
but is faster, great. But please don't expect euphoria on this horrible task
from my side ;-)
So, I would appreciate that you have a very careful look at the ap_hook_call()
cand ap_hook_use() functions and help me to only _optimize_ them - now that
they proved to be portable and working. One idea is to change the string
comparisons to an ID lookup, etc.
Perhaps you have more optimizing ideas?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
