apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: APR_LOCK_DEFAULT ordering
Date Wed, 20 Mar 2002 18:20:34 GMT
Jim Jagielski <jim@jaguNET.com> writes:

> Jeff Trawick wrote:
> > 
> > Jim Jagielski <jim@jaguNET.com> writes:
> > 
> > > Are people happy with the priority order of the accept mutex?
> > > Right now it's flock -> sysvsem -> fcntl -> pthread.
> > > 
> > > I think it should be pthread -> sysvsem -> fcntl -> flock, which
> > > is what 1.3 has...
> > 
> > I realize everybody has jumped in and +1-ed you, but I don't see how
> > you can compare the two orders which you stated above.
> > 
> > I would express the current APR default selection (configure.in, line
> > 1303) this way:
> > 
> > 1st choice :      fcntl
> > 2nd        :      pthread
> > 3rd        :      flock
> > 4th        :      SysV sem
> 
> But proc_mutex.c has the below:
> 
>     case APR_LOCK_DEFAULT:
>     #if APR_USE_FLOCK_SERIALIZE
>             new_mutex->inter_meth = &apr_proc_mutex_unix_flock_methods;
>     #elif APR_USE_SYSVSEM_SERIALIZE
>             new_mutex->inter_meth = &apr_proc_mutex_unix_sysv_methods;

If that were #if apr_HAVE_flock_serialize instead of
apr_USE_flock_serialize then I'd believe you.

But since it is referencing apr_USE_flock_serialize it is making use
of the choices made at configure time, and thus the order of the logic
here under APR_LOCK_DEFAULT is irrelevant.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message