At 11:00 AM -0400 8/28/01, Jeff Trawick wrote:
>
>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.
That's cool.
> > >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.
Agreed... But there have been times when, as an admin, I wished that
I had the capability... this is especially true for those cases where
people generate one build that is supposed to be installed and used
on a variety of similar-platforms-but-different-specifics (eg: all
running Solaris 8, but with different numbers of CPUs, etc). Testing
is showing that more runtime control over the whole accept mutex is
needed :)
>
>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?
Because, at least with the systems I've been testing, it appears to
work OK on OS X, and, as such, we should allow others to have the
choice. I've no idea if it works under IRIX, and having it as
a compiled default implies that we've tested it as such... Basically,
I want people to be able to use any of the compiled-in methods and
have Apache work (maybe not the fastest, but at least we know it
works). If we find out that NONE is supported and viable on
other platforms, we'll change things to make it a compiled default,
but it's premature to do it *now* without that knowledge.
>
>How can default_mutex_method() ever fail? Doesn't that imply a code
>bug in the configuration of mutex methods?
More a compile bug, but yeah, it's designed to handle the traditional
"should never happen" situation.
>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());
>
Yeah... But init_mutex_method needs to handle errors as well... So
we're looking at, basically, defensive coding that pumps info
into a function which is smart enough to handle bogus info. If
default_mutex_method() returned 'unknown' then maybe it wouldn't
be so objectionable :)
PS: partly, it's my own adversion to asserts :) :)
--
===========================================================================
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
