> 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...
I still don't grok why SingleListen is needed. In fact, it seems down right dangerous
and
I am -1 on this directive until someone bashes me with a clue stick :-)
Does everyone understand the S_L_U_A optimization? Apache httpd must call accept() to
pick up inbound connections. Apache httpd runs with multiple threads/processes that all
call accept() to pick up connections. The issue is this: do we allow all the
threads/processes to all call/block in the accept() waiting for connections? The
answer
depends on the capabilities of the OS, specifically how accept() is implemented in the
OS.
I know of at least two problems with allowing multiple threads/processes to block in
accept():
1. thundering herd
This is the commonly cited problem. When a connection comes in, ALL the threads/procs
blocked on the accept wake up but only one is selected to accept the connection. This
is a
performance problem.
2. lock-ups and seg faults
Some systems have some funky timing windows inside the accept() call that will cause
threads to hang and or seg fault inside the accept
The common solution to fix this problem is to mutex access to the accept() call. The
'problem' with this solution is that it introduces two additional system call per
handled
connection (lock and unlocl).
Some OSes have implemented versions of accept() that do not exhibit the problems above.
For these OSes, it is okay to allow multiple threads/procs into the accept call at
once,
saving the overhead of making an additional lock/unlock call per connection. Apache
recognizes these systems by setting the S_L_U_A define in ap_config.h. If S_L_U_A is
defined for a particular version of an OS, that tells Apache httpd that it is okay to
allow multiple threads/proces into the accept(). So S_L_U_A is defined for those
systems
that support it, and it is not defined for those systems that do not support it.
If httpd is configured with multiple listeners, S_L_U_A is irrelevant because you have
to
select() before calling accept(). And to the best of my knowledge, it is always bad to
have multiple threads/processes block in select(), for all OS'.
In the multi listener config, SingleListen will enable the admin to force httpd to make
all the threads/processes to block in accept, even if the system cannot reliable
support
this. Why is this good? The only benefit I see to SingleListen is to enable an admin
to
turn -off- the S_L_U_A optimization in the single listener case. I have never seen the
need to do this.
Bill
