httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Comments on accept-mutex/single-listen patch ??
Date Tue, 28 Aug 2001 15:00:07 GMT
Jim Jagielski <jim@jaguNET.com> writes:

> 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.

The order it checks for (at the moment :) ) is sysvsem, flock, pthread
mutex, fcntl.  The last match wins (i.e., fcntl is preferred).  This
can be overridden on a platform basis in apr_hints.m4 by setting the
variable apr_lock_method. 

> >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.

I'm not totally against it, it just seems that it is for playing
around (sort of like USE_NONE_SERIALIZED_ACCEPT) or trying to work
around an Apache bug (i.e., maybe there is some platform/version where
we're supposed to turn on SINGLE_LISTEN_UNSERIALIZE_ACCEPT but don't).
Why can't they compile this in?  This would seem to be useful in
extremely rare circumstances, and only for somebody who really knows
what they are doing.

> >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.

Why would a platform not support NONE?  I guess I don't understand
what you mean by "support".  Surely you don't mean that it is a wise
thing to do on any of the platforms for which you chose to turn on
HAVE_NONE_SERIALIZED_ACCEPT???

HAVE_NONE_xxx means that you can turn the accept mutex into a no-op,
even in the multiple-listener case.  If we can play around with this
on one platform (e.g., Darwin), why can't we play around with this
everywhere?

> > > +		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?

> 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.

How can default_mutex_method() ever fail?  Doesn't that imply a code
bug in the configuration of mutex methods?

Isn't it better to ap_assert() right in default_mutex_method() than to
ignore the problem and pass init_mutex_method() something bogus (like
"Request[ed] serialized accept method not available")?

Here is the line I'm looking at:

+	init_mutex_method(default_mutex_method());

Thanks,

Jeff

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message