You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2001/08/28 15:42:23 UTC
Comments on accept-mutex/single-listen patch ??
Anyone get a chance to look over and try out the latest patch?
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
At 11:35 AM -0400 8/28/01, Jeff Trawick wrote:
>
>The directive would seem to only be useful for a platform/version that
>has no thundering herd problem with accept() and where Apache's
>ap_config.h has not yet been tweaked to indicate that. Is this a
>real-life problem that we need to solve, or is it rare enough that the
>user can use the existing compile-time mechanism until Apache's
>ap_config.h is fixed and we can avoid adding another directive.
>
recall that we can also *disable* it as well, which can be a factor
on multi-CPU systems... Sometimes settings which are "ok" for
a specific platform may not be optimal for an *instance* of that
platform.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> > > >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.
>
> I disagree. Compiling in SINGLE_LISTEN_UNSERIALIZE_ACCEPT means that
> I have to no up front exactly how the server will be used. What if I am compiling
> one binary to be used on 50 machines (big fortune 2500 companies do this a lot,
> so that they have a common interface). On some of those machines (intranet),
> I may only want one port, so I want to be able to use S_L_U_A, on others
> (Internet), I want two ports (one SSL on regular), so I don't want to use S_L_U_A.
S_L_U_A already handles this capability. When S_L_U_A is defined, you
still get a mutex when there is more than one port. You skip the
mutex only when there is a single port (hence the leading "S_L_").
> I have always thought that being able to turn this on and off at run-time would
> be very cool and useful.
The directive would seem to only be useful for a platform/version that
has no thundering herd problem with accept() and where Apache's
ap_config.h has not yet been tweaked to indicate that. Is this a
real-life problem that we need to solve, or is it rare enough that the
user can use the existing compile-time mechanism until Apache's
ap_config.h is fixed and we can avoid adding another directive.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
Posted by Ryan Bloom <rb...@covalent.net>.
> > >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.
I disagree. Compiling in SINGLE_LISTEN_UNSERIALIZE_ACCEPT means that
I have to no up front exactly how the server will be used. What if I am compiling
one binary to be used on 50 machines (big fortune 2500 companies do this a lot,
so that they have a common interface). On some of those machines (intranet),
I may only want one port, so I want to be able to use S_L_U_A, on others
(Internet), I want two ports (one SSL on regular), so I don't want to use S_L_U_A.
I have always thought that being able to turn this on and off at run-time would
be very cool and useful.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> I'm not going to "fight" for it if it sacrifices the AcceptMutex
> stuff. *THAT* is a real, obvious need, and anyone who doesn't think
> so has never actually *used* Apache in a sys-admin/webmaster
> environment.
There is no way that anything having to do with SingleListen is going
to sacrifice the AcceptMutex stuff. Even if you get disgusted
somebody else will commit it.
AFAICT, nobody here thinks that AcceptMutex isn't needed. OTOH, I
don't think anybody is on the same wavelength with you
w.r.t. "AcceptMutex none" :)
My guess is that SingleListen would be misunderstood/misused far more
often than gainfully used. Even in a mixed-os-level environment there
can be other reasons to recompile apache+modules specifically for the
uplevel boxes.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
Peace!
I'll commit minus SingleListen :)
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Here's the specific issue I'm trying to address with SingleListen, and
> the entire mutex-at-runtime... I build one version of Apache and
> implement it on my suite of servers, say all are running OS Foo 3.4.
> Now some of those servers are single CPU, some are multiCPU. I'd like
> to avoid having separate builds for individual machines. Now say that
> 3.5 comes out, and it supports S_L_U_A... I install it on some
> machines, but not all. It would be nice to be able to continue to use
> the same build of Apache for those as well. I want to give sys-admins
> finer control and avoid the need for recompiles as much as possible.
>
> True, the probability (and usefullness) of the latter is a bit less
> than the former, but it would be nice, and it's a logical extension
> of the concept.
All you gain by introducing SingleListen is the ability to serve requests slightly faster
on OS Foo 3.5 using a binary compiled under OS Foo 3.4. That's it. IMHO, this small gain
is more than offset by the additional complexity of the server (the code), additional
complexity of learning and understanding an obscure configuration directive (do you want
to teach every sysadmin the socket API and how Apache accepts connections? That knowledge
is prereq to understanding how the SingleListen config directive works), and the real
possibility of enabling a sysadmin to configure a system that fails intermittently in
really hard to debug ways.
Bill
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
Here's the specific issue I'm trying to address with SingleListen, and
the entire mutex-at-runtime... I build one version of Apache and
implement it on my suite of servers, say all are running OS Foo 3.4.
Now some of those servers are single CPU, some are multiCPU. I'd like
to avoid having separate builds for individual machines. Now say that
3.5 comes out, and it supports S_L_U_A... I install it on some
machines, but not all. It would be nice to be able to continue to use
the same build of Apache for those as well. I want to give sys-admins
finer control and avoid the need for recompiles as much as possible.
True, the probability (and usefullness) of the latter is a bit less
than the former, but it would be nice, and it's a logical extension
of the concept.
I'm not going to "fight" for it if it sacrifices the AcceptMutex
stuff. *THAT* is a real, obvious need, and anyone who doesn't think
so has never actually *used* Apache in a sys-admin/webmaster
environment.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Thu, 30 Aug 2001, Jim Jagielski wrote:
> To my mind, AcceptMutex is key, and if SingleListen needs to go
> then fine...
IMHO AcceptMutex already allows you to shoot yourself in the foot. On some
platforms also allowing SingleListen shooting would be fine.
I'am still trying to actually prove that it does -not- work on
Darwin/MacOS-X. (Though on Solaris 2.6 it is easily shown to be deadly).
There is certianly (sofar) seems safe to do - and perform well (against
ab).
Dw
Re: Comments on accept-mutex/single-listen patch ??
Posted by Bill Stoddard <bi...@wstoddard.com>.
> At 4:29 PM -0400 8/29/01, Bill Stoddard wrote:
> >
> >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 :-)
>
> I agree that it's dangerous... The intent was to make as much of the accept
> mutex configuration runtime as possible, and SingleListen was easy to do...
> Sort of having the capability to adjust during runtime (on or off) on
> a platform by platform basis in real-world conditions.
>
> To my mind, AcceptMutex is key, and if SingleListen needs to go
> then fine
+1 AcceptMutex
-1 SingleListen
Bill
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
At 4:29 PM -0400 8/29/01, Bill Stoddard wrote:
>
>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 :-)
I agree that it's dangerous... The intent was to make as much of the accept
mutex configuration runtime as possible, and SingleListen was easy to do...
Sort of having the capability to adjust during runtime (on or off) on
a platform by platform basis in real-world conditions.
To my mind, AcceptMutex is key, and if SingleListen needs to go
then fine...
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Marc Slemko <ma...@znep.com>.
On Wed, 29 Aug 2001, Bill Stoddard wrote:
> 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'.
Well... there may be performance tradeoffs, but the real reason why
we _MUST_ serialize in this case for robustness reasons is due to
a possible starvation condition.
Say you have two listening sockets, x and y. If a request comes
in on socket x, then one or more processes will go from select()ing
on sockets {x, y} to accepting on x. If there is only one connection,
then those other processes will be blocked until they get another request
on x. Meanwhile, there may be no processes left selecting on {x, y} which
means no requests on y will be serviced. We solve that by making sure
only one process will get past the select() stage for each connection
established, with the accept mutex.
Re: Comments on accept-mutex/single-listen patch ??
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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
Re: Comments on accept-mutex/single-listen patch ??
Posted by Marc Slemko <ma...@znep.com>.
On 29 Aug 2001, Jeff Trawick wrote:
> Jim Jagielski <ji...@jaguNET.com> writes:
>
> > At 11:00 AM -0400 8/28/01, Jeff Trawick wrote:
> > >
> > >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 would it not work? fubar kernel?
Woah. Hang on here. Lets step back a second... is someone saying
that we don't need an accept mutex with multiple listen sockets on
some platform? That is completely bogus, given the current code.
Hopefully I am just misunderstanding what people are saying, but...
a bit of background:
The original reason for the accept mutex was because some OSes can not
handle having multiple processes calling accept() on the same socket at
the same time because the kernel just doesn't support it. Many
traditional sysv kernels exhibit this behaviour, for example. Most
"modern" OSes do not.
Later, it also became obvious that it was necessary to avoid
deadlocks (well, starvation anyway) with the multiple listener case
due to a race between select() and accept(). Well, actually, there
are other workarounds for this issue that don't involve a mutex
but they may well not be any less expensive and, in any case, are
not implemented.
The single listen unserialized accept was added as an optimization on
those platforms we know don't have problems with multiple threads in
accept() at once (especially those without the thundering herd
problem... although comparing the cost of the scheduler overhead from
thundering heard with the mutex overhead and implementation isn't easy),
to be used only in the case of a single listener because the starvation
problems do not occur there.
So I don't see how "NONE" is viable on _ANY_ platform in the multiple
listener case. It may seem to "mostly" work, but it is not reliable and
can not be permitted.
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> At 11:00 AM -0400 8/28/01, Jeff Trawick wrote:
> >
> >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 would it not work? fubar kernel?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just noticed some typos (ie: SYSVMEM instead of SYSVSEM)... will fix.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@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...
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jim Jagielski <ji...@jaguNET.com>.
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.
+1
> > + 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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: Comments on accept-mutex/single-listen patch ??
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> Anyone get a chance to look over and try out the latest patch?
> will lose both and deserve neither"
I still have unanswered questions from the post of the first patch.
Here they are again, hopefully with the now-resolved issues trimmed
out.
Thanks,
Jeff
-----------/-----------
Jim Jagielski <ji...@jaguNET.com> writes:
> Comments are welcome... I'd like to commit the patch this week. At
> that point, we port to 2.0, which already has a lot of the
> work done (just need to do the default stuff and handle SingleListen)
which "default stuff" is needed in 2.0?
why is SingleListen needed?
> @@ -433,6 +433,9 @@
> #define JMP_BUF jmp_buf
> #define USE_LONGJMP
> #define USE_FLOCK_SERIALIZED_ACCEPT
> +#define USE_FCNTL_SERIALIZED_ACCEPT
> +#define USE_NONE_SERIALIZED_ACCEPT
> +#define DEFAULT_SERIALIZED_ACCEPT_METHOD flock
> #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
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.
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/include/http_main.h,v
> retrieving revision 1.36
> diff -u -r1.36 http_main.h
> --- src/include/http_main.h 2001/01/15 17:04:34 1.36
> +++ src/include/http_main.h 2001/08/20 18:19:42
> @@ -130,6 +130,11 @@
>
> void setup_signal_names(char *prefix);
>
> +/* 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?
-----------------/--------------
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Comments on accept-mutex/single-listen patch ??
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On Tue, 28 Aug 2001, Jim Jagielski wrote:
> Anyone get a chance to look over and try out the latest patch?
Looking at it.. (And trying to compare it with what I've got here to make
sure I still have all the functionality I needed). Seems all cool sofar.
Dw