Jim Jagielski <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
