apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: APR_LOCK_DEFAULT ordering
Date Wed, 20 Mar 2002 18:18:52 GMT
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;
    #elif APR_USE_FCNTL_SERIALIZE
            new_mutex->inter_meth = &apr_proc_mutex_unix_fcntl_methods;
    #elif APR_USE_PROC_PTHREAD_SERIALIZE
            new_mutex->inter_meth = &apr_proc_mutex_unix_proc_pthread_methods;
    #else 
            return APR_ENOTIMPL; 
    #endif

And APR_LOCK_DEFAULT is what ap_accept_lock_mech is set to in mpm_common...
-- 
===========================================================================
   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" - T.Jefferson

Mime
View raw message