httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: ANNOUNCE: MM library, version 1.0b1
Date Sat, 13 Mar 1999 11:45:57 GMT

In article <> you wrote:

> That's true... Still, the performance issue still's valid. fcntl()
> can really suck wind.
>> I don't see why you wouldn't use the exact same config we've been using
>> forever for apache's shared mem and locking. 
> Especially since we already _know_ those...

As I see it, our current shared memory and locking decision is based just on a
few platform dependent defines. Yes, for most of the platforms this could be
directly translated into the MM_XXX_YYYYY defines which currently GNU Autoconf
generated for the MM library. But the decisions we've in ap_config.h are only
related to the accept mutex and the scoreboard. And I'm not sure whether this
really translates correctly for the MM library. And additionally the
Autoconf-approach adjusts MM also for platforms where we've still no knowledge
on, while the static ap_config.h approach knows only a fixed set of platforms. 

But ok, the whole stuff is abstracted in the MM library: The whole
_configuration_ under compile-time works by including the mm_conf.h header.
How this header was created is not important. I currently create it as a
static header (no dynamic decisions contained) by generating it via GNU
Autoconf. But inside Apache it can also be a header which includes ap_config.h
and makes some decision on it's contents. I've already thought about this
possibility. So, I think the config stuff shouldn't be an issue and be always
solves to our happyness.

What's now more important is that someone reviews the hard-core details of the
library itself...
                                       Ralf S. Engelschall

View raw message