httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src/modules/mpm/prefork prefork.c
Date Fri, 09 Jun 2000 16:44:53 GMT
> From:
> 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
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 | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message