httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Comments on accept-mutex/single-listen patch ??
Date Tue, 28 Aug 2001 14:26:33 GMT
At 10:18 AM -0400 8/28/01, Jeff Trawick wrote:
>which "default stuff" is needed in 2.0?

Last I looked, APR uses the traditional ordering of which
locking method to use. Thus, if SysV, fcntl and flock are
available, APR will choose SysV by default, even if it should
be fcntl. We know which should be the default from the 1.3 code.

>why is SingleListen needed?

Pretty much to make SINGLE_LISTEN runtime rather than compile
time... Again, to give the admins more control over how
Apache handles mutexing.

>So what decides when "USE_NONE_SERIALIZED_ACCEPT" is a choice?  I'd
>think that if you allow it anywhere you'd allow it everywhere, and
>that there'd be no need to define anything in ap_config.h.

It's on an platform-by-platform basis... Again, what we're doing
is telling Apache which mutex methods are *available* on the
platform, not neccessaryly what ones to use. Some platforms
don't support NONE and they shouldn't be given the option to
add it in. We should provide users with as comprehensive a
suite of methods as we can, and let them adjust/use/determine
which ones at runtime. If they are feeling adventurous (or are
in developer-mode) then they can compile in some other suites and
see how they work.

> > 
>> +/* functions for determination and setting of accept() mutexing */
>> +char *default_mutex_method(void);
>> +char *init_mutex_method(char *t);
>> +char *init_single_listen(int flag);
>prefix with "ap_"...  yeah, not everything in 1.3 is
>namespace-protected, but it is trivial for new functions.


> > +		return "Request serialized accept method not available";
>"Requested", not "Request"
> > +		return "Request serialized accept method not available";
>same as previous comment, but I'd think one of these should never
>fail... how about ap_assert() in one of them instead of returning an
>error that we shouldn't have logic to check for?

The 'Request' refers to the actual HTTP request (ie: serialized accept method
used in the request) but yeah, I agree that it's confusing. And Requested
makes more sense.

Recall that these sections deal with runtime checking... If someone
adds 'AcceptMethod flark' to httpd.conf, we want Apache to complain
and die at config read, which is what happens.
   Jim Jagielski   [|]   [|]
      "A society that will trade a little liberty for a little order
                   will lose both and deserve neither"

View raw message