httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Khimenko Victor" <>
Subject Re: 1.3.7/1.4.0 Release
Date Mon, 21 Jun 1999 18:36:14 GMT
21-Jun-99 18:05 you wrote:

> In article <> you wrote:

>> There's a few patches that are "supposed" to be commited. There's the
>> mass-vhosting one and Ralf's EAPI for example. Ralf's 'mm' would be
>> nice but we'd need to have it fit into the source since it's
>> autconf driven right now :(
>> Unless someone else adds the vhost one, I'll do it late tonight.

> I'll work on EAPI integration perhaps tomorrow.  Why is the Autoconf stuff of
> MM a problem, Jim?  For inclusion of MM into the source tree all we have to do
> is to strip the MM distribution to the essential files and call it's configure
> script as "cd src/lib/mm && configure >configure.log 2>&1" in src/Configure
> plus a few failure-checks after it and a " + configuring MM (please be
> patient)" before.  That should be ok. Comments? The license stuff should be
> harmless: Autoconf-*generated* scripts aren't GPL and the advertisement clause
> of MM you can ignore for Apache, of course.

I just want to remind that there are exists different version of hooks API.
You can read Ralf's opinions [and my minimal comments] below and you can find
thing itself at
Just hooks api and context API are changed (ok, more like "rewritten by
EAPI motives" :-) -- MM stuff and additional hooks (and documentation) are
borrowed from EAPI without changes.

Ralf was not convinced to switch on this version but I'm still not sure if
Ralf's version is really superior. Especially for general hooks API. PLEASE
take a look. BTW looks like Ralf mixed problems of my hooks API and my
context API. They are NOT RELATED in any way ! You can use my hooks API with
Ralf's context API (so 2a and 3a complains are just irrelevant).

-- cut --
>From sch57!!rse Sun Jan 24 23:08:30 1999
Received: by (UUPC/@ v7.00, 06Mar97) with UUCP
          id AA03937; Sun, 24 Jan 1999 23:08:30 +0300 (MSK)
Received: from ( [])
        by (8.8.7/8.8.7) with SMTP id VAA19973
        for <>; Sun, 24 Jan 1999 21:52:22 +0300
Received: (qmail 21776 invoked by uid 66); 24 Jan 1999 18:52:50 -0000
Received: from en by slarti with UUCP; 24 Jan 1999 18:52:50 -0000 (GMT)
Received: by (Sendmail 8.9.2)
        id TAA13967; Sun, 24 Jan 1999 19:52:50 +0100 (CET)
Date: Sun, 24 Jan 1999 19:52:50 +0100
From: "Ralf S. Engelschall" <>
Subject: Your EAPI variant
Message-ID: <>
Mime-Version: 1.0
X-Mailer: Mutt 0.95.1i
Organization: Engelschall, Germany.
X-PGP-Fingerprint: 00 C9 21 8E D1 AB 70 37 DD 67 A2 3A 0A 6F 8D A5
Lines: 116
Content-Type: text/plain; charset=us-ascii
Content-Length: 6860

[goes also to Martin Kraemer who discussed EAPI with us in the past]

I've now found time the last days to check your EAPI variant in more detail
and I've written down a few observations for you. Sorry for the long delay,
but I was _VERY_ busy (actually I'm still very busy, but I couldn't let you
wait even longer, of course ;-). Please treat my points just as my personal
point of view and feel free to critize me for my opinion when my expressed
points should sound not acceptable for you.

1. Very good points:

- typesafe: That's the thing I like very much about your EAPI variant. With
  your variant calling hooks incorrectly or providing incorrect hooks cannot
  occur. That's very good! (The reason why I cannot provide this with my EAPI
  variant is mainly because I (intentionally) declare signatures only once.)

- extendible without updating the dispatching functions: This is the *major*
  advantage of your variant, I think.  Because for my variant the possible
  signatures have to be hard-coded into the ap_hook.c (although they're
  automatically generated), which means that when you want to use an
  additional esoteric signature which still isn't implemented you have to at
  least once let ap_hook.c updated by a Perl-based procedure.  The reason is
  because in ANSI C one cannot dynamically construct the arguments on the
  stack for a function call (in scripting languages that's easy, but it's not
  possible in a portable way for ANSI C). So, my hook calling mechanism has to
  dispatch over _all possible_ function signatures :-(. You can avoid this in
  your EAPI variant because you declare special functions for each hook.
  That's a _major_ advantage in your EAPI variant, of course. Very well done.

- the return type of a hook call can be directly used like `x = func(y)'
  instead of the `func(&x, y)' my EAPI variant has to use. I tried hard to
  provide this with my EAPI variant, but it's not possible with a general hook
  calling mechanism based on ANSI C. Because in portable ANSI C one cannot
  have different return values for a function (and even union's cannot be used
  here because the signature is not implicitly known to the caller). So, I
  like this feature of your EAPI very much.

2. Questionable points (IMHO):

- inline: This optimization idea is interesting, but the drawback is that
  this feature is only available with C++ or GNU C compilers. So on a lot of
  platforms it doesn't really optimize the stuff. And even when it optimizes
  one step of your calls, it still isn't faster than my original EAPI calling
  way IMHO.  Because the internal functions have to be still called, even for
  your EAPI variant.

[Khim: Yes, in most cases additional internal functions are called. But one
case (ap_hook_call) is fully inlined. And IMO it's the only hook API call to
be called A LOT OF time...]

- use numbers instead of strings to identify hooks: This again
  is a very interesting idea, but it also has some drawbacks: First it's not
  clear to me that this _really_ speeds things up (the number of hooks is not
  large, just around 10-20, and doing string-comparisons does not really mean
  that the whole matching is slow all the time because matching strings with
  strcmp() is usually implemented very fast). Second the string=>number
  mapping needs an extra programming step at _every_ usage context (the source
  file) of the hook. This makes the API a lot more complicated for the user.
  And third, from optimization hints Dean Gaudet (our optimization god) gave
  for Apache, the real bottleneck of Apache are not some CPU cycles spent on
  those things. The real bottleneck is still I/O. So even when this speeds up
  your processing, it's not clear that it also speeds up Apache's processing
  as a whole in contrast to my EAPI variant (but that was your major point of
  concern when I remember correctly, right?).

3. Not such good points (IMHO):

- hook id numbers stay around as global variables `XXX_num': I don't like
  those global variables. Especially for mod_ssl 2.1 I've dramatically reduced
  all global variables. Actually there is no longer a single global variable.
  Just the EAPI stuff uses a few. But with your EAPI variant those XXX_num
  variables occur at every use context again. This is a little bit ugly and
  I'm especially not convinced that this doesn't break Win32 where a threading
  process model is used.

- signature definition has to be repeated in both the producer and consumer
  context of the hook: This is needed for your `typesafety' but it means you
  have to sync syntax in all places. And it makes the API less thin.  And a
  thin but general API was one of my major goals with my EAPI variant.  Which
  leads me to the next point...

- "bloatware": Hmmm... I was shocked in the past when you said my EAPI is
  "bloatware" because it seemed to you a little but too over-coded. But I've
  now to admit that I'm the opinion that your EAPI variant could be also
  considered bloatware.  For instance the ap_hook.h header is horribly long
  and contains a lot of special cases and variants which are very hard to
  understand and follow. But beside this, what I address more is the API you
  use. My API is _very_ thin. It just use 8 functions for the complete hook
  mechanism, while your EAPI hook mechanism uses 24 functions. That's a lot
  more complexity for the user for just the same functionality. Sure, I know
  that you have to do it this way, but nevertheless I've to count this not as
  an advantage.

- optimization vs. replacement: And finally we have some NIH-problem, of
  course ;-). No, not really. I was just kidding. The real problem for me was
  just that you called your EAPI variant an "optimized variant" of my EAPI.
  But actually your EAPI variant is a complete replacement for my EAPI as it
  looks to me. But as I tried to explain above, I'm not convinced that the
  advantage of a few gained CPU-cycles is worth a less-thin and easy API.

So, as you can see, my opinion is half-way "great stuff" and half-way "I'm not
convinced of it's proposed advantages". Nevertheless I think you've done a
great job with your EAPI variant. Especially because you use it for a lot more
things than just integrating mod_ssl (what I do). For instance your
mod_include=>mod_perl integration is a very good use case for EAPI. That's
really neat. Very well done!

But I've to admit that I currently don't plan to replace my EAPI with your
variant, although it has some advantages (typesafe, extendible, nicer return
type handling).  Because I'm not convinced that the optimization gain is
really essential and also worth the drawbacks (global variables, repeated
signature declaration, very complex code).

Nevertheless thanks for your Apache-related coding efforts and for supporting
the Apache and mod_ssl projects this way.

                                       Ralf S. Engelschall
-- cut --

View raw message