You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/06/09 16:57:47 UTC
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
> Note: The TPF and SGI folks need to each APR how to get the most
> efficient lock on those platforms. (For SGI it depends on whether
> or not we're building for SMP.)
I assume your asking here how to tell APR which lock to use. I don't
think you can, yet. This is something that needs to be done soon. Then,
the hints file can pass this information around.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Rodent of Unusual Size wrote:
>
> Which picture was this?
http://www.apache.org/~fanf/fight.jpg
nyuk, nyuk, nyuk!
Greg
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Trawick wrote:
>
> By the way... Dirk's picture was great. I need to put copies of it
> next to all my computers just to keep things in perspective :)
Which picture was this?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by rb...@covalent.net.
> > Does that mean that the most efficient lock is no lock at all? That
isn't
> > up to APR to implement. APR implements a locking scheme, it is up to the
> > application/platform to decide if that scheme is a good choice or
> > not.
>
> No, I meant something else:
>
> There is no APR equivalent of what used to be inside
> USE_USLOCK_SERIALIZED_ACCEPT and USE_TPF_CORE_SERIALIZED_ACCEPT in
> prefork.c. This was code to make a system-specific syscall to use a
> system-specific type of mutex. I just meant that SGI and TPF folks
> could add code to APR to map APR locks onto those primitives. Until
> that time, SGI and TPF must use fcntl, flock, sysvsem, or whatever
> else APR currently implements.
Ahhhh. This makes sense to me now. Thank you for the clarification.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: rbb@covalent.net
> Date: Fri, 9 Jun 2000 08:24:16 -0700 (PDT)
>
>
> > > > Note: The TPF and SGI folks need to each APR how to get the most
> > > > efficient lock on those platforms. (For SGI it depends on whether
> > > > or not we're building for SMP.)
> >
> > Telling APR which lock to use via hints.m4 is something somebody needs
> > to implement before long, but the TPF and SGI issue I meant to allude
> > to here is that APR has no implementation of the most efficient locks
> > on those platforms. prefork did, but not after this commit. I won't
> > lose any sleep over it (TPF and SGI can if they so choose), but I
> > thought I would mention it.
>
> Does that mean that the most efficient lock is no lock at all? That isn't
> up to APR to implement. APR implements a locking scheme, it is up to the
> application/platform to decide if that scheme is a good choice or
> not.
No, I meant something else:
There is no APR equivalent of what used to be inside
USE_USLOCK_SERIALIZED_ACCEPT and USE_TPF_CORE_SERIALIZED_ACCEPT in
prefork.c. This was code to make a system-specific syscall to use a
system-specific type of mutex. I just meant that SGI and TPF folks
could add code to APR to map APR locks onto those primitives. Until
that time, SGI and TPF must use fcntl, flock, sysvsem, or whatever
else APR currently implements.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by rb...@covalent.net.
> > > Note: The TPF and SGI folks need to each APR how to get the most
> > > efficient lock on those platforms. (For SGI it depends on whether
> > > or not we're building for SMP.)
>
> Telling APR which lock to use via hints.m4 is something somebody needs
> to implement before long, but the TPF and SGI issue I meant to allude
> to here is that APR has no implementation of the most efficient locks
> on those platforms. prefork did, but not after this commit. I won't
> lose any sleep over it (TPF and SGI can if they so choose), but I
> thought I would mention it.
Does that mean that the most efficient lock is no lock at all? That isn't
up to APR to implement. APR implements a locking scheme, it is up to the
application/platform to decide if that scheme is a good choice or not.
>
> By the way... Dirk's picture was great. I need to put copies of it
> next to all my computers just to keep things in perspective :)
Yeah, we had a good time with it. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Date: Fri, 9 Jun 2000 11:31:57 -0400 (EDT)
> From: David Williams <dw...@cisco.com>
>
> On Fri, 9 Jun 2000, Jeff Trawick wrote:
>
> > Telling APR which lock to use via hints.m4 is something somebody needs
> > to implement before long, but the TPF and SGI issue I meant to allude
> > to here is that APR has no implementation of the most efficient locks
> > on those platforms. prefork did, but not after this commit. I won't
> > lose any sleep over it (TPF and SGI can if they so choose), but I
> > thought I would mention it.
>
> Is that something that could be added to mpm/prefork/config.m4? Or is
> there no way for configure to easily check the platform by a "uname"
> type call. For alpha 3, I needed to add this to config.m4:
> AC_DEFINE(USE_FCNTL_SERIALIZED_ACCEPT,,
> [Define this if File Control serialization will be used.])
> for the accept_mutex_on() to work properly on unix.
>
> thanks,
> -david
You shouldn't need anything like that in config.m4 anymore (well, once
you get the current level of code).
prefork.c is now fixed so that it will always get an accept mutex for
the multiple listen case and unless SINGLE_LISTEN_NO_SERIALIZED_ACCEPT
is defined it will get an accept mutex for the single listen case.
prefork.c no longer decides which syscalls to use for the accept
mutex; that is deferred to APR.
If you want to tell APR to use SysV sems instead of fcntl() locks
(just an example): there is no clean way to do that yet...
Eventually there will be stuff in hints.m4 to choose the best known
mutex primitive for various platforms.
Currently you can play tricks in src/lib/apr/locks/unix/lock.h after
apr_private.h is included and before any #ifdef APR_USE_xyz_SERIALIZE,
but I wouldn't recommend that for general use :)
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: rbb@covalent.net
> Date: Fri, 9 Jun 2000 08:35:39 -0700 (PDT)
> This is what I thought Jeff meant at first. In order to fix this problem,
> we need to do two things:
>
> 1) Add the ability to specify locking mechanism on the APR ./configure
> command line
>
> 2) For platforms that have specific locking needs, add that to the
> hints.m4 file.
>
> Step 1 will take a matter of hours once somebody decides to do it. Step 2
> should take minutes for the platforms we have information for from
> 1.3.
Not really what I meant, but I agree 100% that it is needed :) I
didn't think of the ./configure command line possibility... that will
be nice.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by rb...@covalent.net.
> > Telling APR which lock to use via hints.m4 is something somebody needs
> > to implement before long, but the TPF and SGI issue I meant to allude
> > to here is that APR has no implementation of the most efficient locks
> > on those platforms. prefork did, but not after this commit. I won't
> > lose any sleep over it (TPF and SGI can if they so choose), but I
> > thought I would mention it.
>
> Is that something that could be added to mpm/prefork/config.m4? Or is
> there no way for configure to easily check the platform by a "uname"
> type call. For alpha 3, I needed to add this to config.m4:
> AC_DEFINE(USE_FCNTL_SERIALIZED_ACCEPT,,
> [Define this if File Control serialization will be used.])
> for the accept_mutex_on() to work properly on unix.
This is what I thought Jeff meant at first. In order to fix this problem,
we need to do two things:
1) Add the ability to specify locking mechanism on the APR ./configure
command line
2) For platforms that have specific locking needs, add that to the
hints.m4 file.
Step 1 will take a matter of hours once somebody decides to do it. Step 2
should take minutes for the platforms we have information for from 1.3.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by David Williams <dw...@cisco.com>.
On Fri, 9 Jun 2000, Jeff Trawick wrote:
> > From: rbb@covalent.net
> > Date: Fri, 9 Jun 2000 07:57:47 -0700 (PDT)
> >
> >
> > > Note: The TPF and SGI folks need to each APR how to get the most
> > > efficient lock on those platforms. (For SGI it depends on whether
> > > or not we're building for SMP.)
> >
> > I assume your asking here how to tell APR which lock to use. I don't
> > think you can, yet. This is something that needs to be done soon. Then,
> > the hints file can pass this information around.
> >
> > Ryan
>
> I wasn't very clear, and the typo didn't help :(
>
> Telling APR which lock to use via hints.m4 is something somebody needs
> to implement before long, but the TPF and SGI issue I meant to allude
> to here is that APR has no implementation of the most efficient locks
> on those platforms. prefork did, but not after this commit. I won't
> lose any sleep over it (TPF and SGI can if they so choose), but I
> thought I would mention it.
Is that something that could be added to mpm/prefork/config.m4? Or is
there no way for configure to easily check the platform by a "uname"
type call. For alpha 3, I needed to add this to config.m4:
AC_DEFINE(USE_FCNTL_SERIALIZED_ACCEPT,,
[Define this if File Control serialization will be used.])
for the accept_mutex_on() to work properly on unix.
thanks,
-david
Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: rbb@covalent.net
> Date: Fri, 9 Jun 2000 07:57:47 -0700 (PDT)
>
>
> > Note: The TPF and SGI folks need to each APR how to get the most
> > efficient lock on those platforms. (For SGI it depends on whether
> > or not we're building for SMP.)
>
> I assume your asking here how to tell APR which lock to use. I don't
> think you can, yet. This is something that needs to be done soon. Then,
> the hints file can pass this information around.
>
> Ryan
I wasn't very clear, and the typo didn't help :(
Telling APR which lock to use via hints.m4 is something somebody needs
to implement before long, but the TPF and SGI issue I meant to allude
to here is that APR has no implementation of the most efficient locks
on those platforms. prefork did, but not after this commit. I won't
lose any sleep over it (TPF and SGI can if they so choose), but I
thought I would mention it.
By the way... Dirk's picture was great. I need to put copies of it
next to all my computers just to keep things in perspective :)
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...