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/06/22 15:20:20 UTC
Accept mutex
I've been toying with the idea of making the accept mutex selection
a runtime rather than compile-time option. This makes sense to me
for certain applications. At present, however, APR decides the mutex
type and Apache uses that. So we either need some way for APR to
determine all possible available options, and then "enable" them
(provide the required calls) and then have an Apache directive do the
required right-thing to pick the one you want.
One way would be to add another argument to the APR call that defines
the lock type (enum would be best, 'natch). Whatcha think?
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"It's *good* to be the King."
Re: Accept mutex
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
Note also that an APR_LOCK_ALL lock will likely need to select an
interprocess lock mechanism *and* an intraprocess lock mechanism*.
*though currently APR never has any choices to make
w.r.t. intraprocess lock mechanism
--
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: Accept mutex
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
Note also that an APR_LOCK_ALL lock will likely need to select an
interprocess lock mechanism *and* an intraprocess lock mechanism*.
*though currently APR never has any choices to make
w.r.t. intraprocess lock mechanism
--
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: Accept mutex
Posted by Bill Stoddard <bi...@wstoddard.com>.
I have expressed my distaste for the "one mutex fits all" approach of APR for quite a
while. +1
Bill
----- Original Message -----
From: "Jim Jagielski" <ji...@jaguNET.com>
To: <ne...@apache.org>; <de...@apr.apache.org>
Sent: Friday, June 22, 2001 9:20 AM
Subject: Accept mutex
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need some way for APR to
> determine all possible available options, and then "enable" them
> (provide the required calls) and then have an Apache directive do the
> required right-thing to pick the one you want.
>
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
> --
> ===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "It's *good* to be the King."
>
Re: Accept mutex
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yes, in 1.3.x is pretty trivial. It's a tiny bit more complex in
2.0, but not much. I agree that it makes sense for both versions.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"It's *good* to be the King."
Re: Accept mutex
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yes, in 1.3.x is pretty trivial. It's a tiny bit more complex in
2.0, but not much. I agree that it makes sense for both versions.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"It's *good* to be the King."
Re: Accept mutex
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
Actually; I've just written this for an in-house experiment at covalent;
by just using function pointers. See attached hack to get an idea. It is
not ready for submittal - as it does not yet have sensible default choise.
Dw
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need some way for APR to
> determine all possible available options, and then "enable" them
> (provide the required calls) and then have an Apache directive do the
> required right-thing to pick the one you want.
>
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
>
Re: Accept mutex
Posted by Cliff Woolley <cl...@yahoo.com>.
On 22 Jun 2001, Jeff Trawick wrote:
> I think I'd rather see it fail.
>
> If an app wants to back down to the default without informing the user
> that they picked an invalid mechanism then it is just an extra couple
> of lines.
+1
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Accept mutex
Posted by Cliff Woolley <cl...@yahoo.com>.
On 22 Jun 2001, Jeff Trawick wrote:
> I think I'd rather see it fail.
>
> If an app wants to back down to the default without informing the user
> that they picked an invalid mechanism then it is just an extra couple
> of lines.
+1
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Accept mutex
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> AcceptMutex fcntl|flock|sysv|pthread|default...
>
> As far as someone choosing a method not supported on that platform,
> then an error-no-start or error-choose-default would be the 2
> options on how Apache/APR should handle that. I think I'd prefer the
> 'choose-default' reaction...
I think I'd rather see it fail.
If an app wants to back down to the default without informing the user
that they picked an invalid mechanism then it is just an extra couple
of lines.
rv = apr_lock_create(aaa, APR_MUTEX_SYSVSEM, bbb);
if (APR_STATUS_IS_ENOTIMPL(rv)) {
rv = apr_lock_create(aaa, APR_MUTEX_DEFAULT, bbb);
}
if (rv != APR_SUCCESS) {
/* handle failure to create a lock */
}
If an app doesn't want to back down to the default ('cause it *is* a
configuration error) then existing code works fine.
If APR has the code to back down to the default then there has to be a
special return code from apr_lock_create() to indicate that the app
got the default and/or some other way for the app to find out that it
didn't get what it asked 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: Accept mutex
Posted by Jeff Trawick <tr...@attglobal.net>.
Jim Jagielski <ji...@jaguNET.com> writes:
> AcceptMutex fcntl|flock|sysv|pthread|default...
>
> As far as someone choosing a method not supported on that platform,
> then an error-no-start or error-choose-default would be the 2
> options on how Apache/APR should handle that. I think I'd prefer the
> 'choose-default' reaction...
I think I'd rather see it fail.
If an app wants to back down to the default without informing the user
that they picked an invalid mechanism then it is just an extra couple
of lines.
rv = apr_lock_create(aaa, APR_MUTEX_SYSVSEM, bbb);
if (APR_STATUS_IS_ENOTIMPL(rv)) {
rv = apr_lock_create(aaa, APR_MUTEX_DEFAULT, bbb);
}
if (rv != APR_SUCCESS) {
/* handle failure to create a lock */
}
If an app doesn't want to back down to the default ('cause it *is* a
configuration error) then existing code works fine.
If APR has the code to back down to the default then there has to be a
special return code from apr_lock_create() to indicate that the app
got the default and/or some other way for the app to find out that it
didn't get what it asked 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: Accept mutex
Posted by rb...@covalent.net.
Well, that all makes sense to me. As does the added reasoning by Jeff,
so........
-1!
Just kidding, +1, I'm behind this 100%. :-)
Ryan
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> Well, that's it basically. APR chooses what's best on a per-platform
> basis, but it might not be the best choice for a per-environment
> basis. For example, on my Foobar box, APR may choose FCNTL, but
> I've enabled/added semaphores and want to use that. Instead of having
> to recompile, it would be nice to be able to simply edit and restart.
> Might also be a factor in resource control as well...
>
> Your concern about "if we do this, how do we determine the default
> mutex" is a good one, and I've been considering a DEFAULT type which
> is the one that APR currently chooses. That way, all would currently
> work as is, but people would have the option in httpd.conf to set
>
> AcceptMutex fcntl|flock|sysv|pthread|default...
>
> As far as someone choosing a method not supported on that platform,
> then an error-no-start or error-choose-default would be the 2
> options on how Apache/APR should handle that. I think I'd prefer the
> 'choose-default' reaction...
>
> At 6:53 AM -0700 6/22/01, <rb...@covalent.net> wrote:
> >
> >Could be cool. But a quick question, what do you expect to gain with
> >this? Is it for experimentation, or do you believe that having multiple
> >mutex types will be useful in the same production server? Would this mean
> >that the Apache code would need to try multiple kinds of locks before it
> >necessarily found one that worked?
> >
>
>
> --
> ===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "It's *good* to be the King."
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Accept mutex
Posted by rb...@covalent.net.
Well, that all makes sense to me. As does the added reasoning by Jeff,
so........
-1!
Just kidding, +1, I'm behind this 100%. :-)
Ryan
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> Well, that's it basically. APR chooses what's best on a per-platform
> basis, but it might not be the best choice for a per-environment
> basis. For example, on my Foobar box, APR may choose FCNTL, but
> I've enabled/added semaphores and want to use that. Instead of having
> to recompile, it would be nice to be able to simply edit and restart.
> Might also be a factor in resource control as well...
>
> Your concern about "if we do this, how do we determine the default
> mutex" is a good one, and I've been considering a DEFAULT type which
> is the one that APR currently chooses. That way, all would currently
> work as is, but people would have the option in httpd.conf to set
>
> AcceptMutex fcntl|flock|sysv|pthread|default...
>
> As far as someone choosing a method not supported on that platform,
> then an error-no-start or error-choose-default would be the 2
> options on how Apache/APR should handle that. I think I'd prefer the
> 'choose-default' reaction...
>
> At 6:53 AM -0700 6/22/01, <rb...@covalent.net> wrote:
> >
> >Could be cool. But a quick question, what do you expect to gain with
> >this? Is it for experimentation, or do you believe that having multiple
> >mutex types will be useful in the same production server? Would this mean
> >that the Apache code would need to try multiple kinds of locks before it
> >necessarily found one that worked?
> >
>
>
> --
> ===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "It's *good* to be the King."
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Accept mutex
Posted by Jim Jagielski <ji...@jaguNET.com>.
Well, that's it basically. APR chooses what's best on a per-platform
basis, but it might not be the best choice for a per-environment
basis. For example, on my Foobar box, APR may choose FCNTL, but
I've enabled/added semaphores and want to use that. Instead of having
to recompile, it would be nice to be able to simply edit and restart.
Might also be a factor in resource control as well...
Your concern about "if we do this, how do we determine the default
mutex" is a good one, and I've been considering a DEFAULT type which
is the one that APR currently chooses. That way, all would currently
work as is, but people would have the option in httpd.conf to set
AcceptMutex fcntl|flock|sysv|pthread|default...
As far as someone choosing a method not supported on that platform,
then an error-no-start or error-choose-default would be the 2
options on how Apache/APR should handle that. I think I'd prefer the
'choose-default' reaction...
At 6:53 AM -0700 6/22/01, <rb...@covalent.net> wrote:
>
>Could be cool. But a quick question, what do you expect to gain with
>this? Is it for experimentation, or do you believe that having multiple
>mutex types will be useful in the same production server? Would this mean
>that the Apache code would need to try multiple kinds of locks before it
>necessarily found one that worked?
>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"It's *good* to be the King."
Re: Accept mutex
Posted by Jim Jagielski <ji...@jaguNET.com>.
Well, that's it basically. APR chooses what's best on a per-platform
basis, but it might not be the best choice for a per-environment
basis. For example, on my Foobar box, APR may choose FCNTL, but
I've enabled/added semaphores and want to use that. Instead of having
to recompile, it would be nice to be able to simply edit and restart.
Might also be a factor in resource control as well...
Your concern about "if we do this, how do we determine the default
mutex" is a good one, and I've been considering a DEFAULT type which
is the one that APR currently chooses. That way, all would currently
work as is, but people would have the option in httpd.conf to set
AcceptMutex fcntl|flock|sysv|pthread|default...
As far as someone choosing a method not supported on that platform,
then an error-no-start or error-choose-default would be the 2
options on how Apache/APR should handle that. I think I'd prefer the
'choose-default' reaction...
At 6:53 AM -0700 6/22/01, <rb...@covalent.net> wrote:
>
>Could be cool. But a quick question, what do you expect to gain with
>this? Is it for experimentation, or do you believe that having multiple
>mutex types will be useful in the same production server? Would this mean
>that the Apache code would need to try multiple kinds of locks before it
>necessarily found one that worked?
>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"It's *good* to be the King."
Re: Accept mutex
Posted by Jeff Trawick <tr...@attglobal.net>.
rbb@covalent.net writes:
> On Fri, 22 Jun 2001, Jim Jagielski wrote:
>
> > I've been toying with the idea of making the accept mutex selection
> > a runtime rather than compile-time option. This makes sense to me
> > for certain applications. At present, however, APR decides the mutex
> > type and Apache uses that. So we either need some way for APR to
> > determine all possible available options, and then "enable" them
> > (provide the required calls) and then have an Apache directive do the
> > required right-thing to pick the one you want.
> >
> > One way would be to add another argument to the APR call that defines
> > the lock type (enum would be best, 'natch). Whatcha think?
>
> Could be cool. But a quick question, what do you expect to gain with
> this? Is it for experimentation, or do you believe that having multiple
> mutex types will be useful in the same production server? Would this mean
> that the Apache code would need to try multiple kinds of locks before it
> necessarily found one that worked?
Take Solaris... Up to a certain number of CPUs/concurrent
connections, Apache works best when the accept mutex is XXX.
Above that level Apache works best when the accept mutex is YYY.
(I don't remember what XXX and YYY are (fcntl, pthread cross-process,
whatever) but this is a real occurrence.)
Also on Solaris... The fcntl() (IIRC) support in the kernel doesn't
get along with Apache + a certain third-pardy module. But fcntl() is
best for most configurations.
--
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: Accept mutex
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
Sander (Temme) and I have been working on this in the last two weeks;
basically it turns out that your best mutex stategy is not just a function
of the OS, but also of the (type of) load, the # of processors and the
speed of those processor's. In particuly - if your bottle neck is a high
mutex rate - you are better off using less processor's with a higher speed
- or you should change strategy.
Hence the patch which we've been testing on 1,2,4 and 8 processor (sun)
machines. But do not expect that work to conclude soonish :-)
Dw
> Could be cool. But a quick question, what do you expect to gain with
> this? Is it for experimentation, or do you believe that having multiple
> mutex types will be useful in the same production server? Would this mean
> that the Apache code would need to try multiple kinds of locks before it
> necessarily found one that worked?
>
> I guess my only thought is that APR chooses the "best" lock for the
> platform based on the groups experience, and what is available. Would
> this change then put the onus of defining which lock type is used back on
> the programmer?
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
>
>
Re: Accept mutex
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
Sander (Temme) and I have been working on this in the last two weeks;
basically it turns out that your best mutex stategy is not just a function
of the OS, but also of the (type of) load, the # of processors and the
speed of those processor's. In particuly - if your bottle neck is a high
mutex rate - you are better off using less processor's with a higher speed
- or you should change strategy.
Hence the patch which we've been testing on 1,2,4 and 8 processor (sun)
machines. But do not expect that work to conclude soonish :-)
Dw
> Could be cool. But a quick question, what do you expect to gain with
> this? Is it for experimentation, or do you believe that having multiple
> mutex types will be useful in the same production server? Would this mean
> that the Apache code would need to try multiple kinds of locks before it
> necessarily found one that worked?
>
> I guess my only thought is that APR chooses the "best" lock for the
> platform based on the groups experience, and what is available. Would
> this change then put the onus of defining which lock type is used back on
> the programmer?
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
>
>
Re: Accept mutex
Posted by rb...@covalent.net.
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need some way for APR to
> determine all possible available options, and then "enable" them
> (provide the required calls) and then have an Apache directive do the
> required right-thing to pick the one you want.
>
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
Could be cool. But a quick question, what do you expect to gain with
this? Is it for experimentation, or do you believe that having multiple
mutex types will be useful in the same production server? Would this mean
that the Apache code would need to try multiple kinds of locks before it
necessarily found one that worked?
I guess my only thought is that APR chooses the "best" lock for the
platform based on the groups experience, and what is available. Would
this change then put the onus of defining which lock type is used back on
the programmer?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Accept mutex
Posted by rb...@covalent.net.
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need some way for APR to
> determine all possible available options, and then "enable" them
> (provide the required calls) and then have an Apache directive do the
> required right-thing to pick the one you want.
>
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
Could be cool. But a quick question, what do you expect to gain with
this? Is it for experimentation, or do you believe that having multiple
mutex types will be useful in the same production server? Would this mean
that the Apache code would need to try multiple kinds of locks before it
necessarily found one that worked?
I guess my only thought is that APR chooses the "best" lock for the
platform based on the groups experience, and what is available. Would
this change then put the onus of defining which lock type is used back on
the programmer?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Accept mutex
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
Actually; I've just written this for an in-house experiment at covalent;
by just using function pointers. See attached hack to get an idea. It is
not ready for submittal - as it does not yet have sensible default choise.
Dw
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need some way for APR to
> determine all possible available options, and then "enable" them
> (provide the required calls) and then have an Apache directive do the
> required right-thing to pick the one you want.
>
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
>