apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Date Mon, 02 Jul 2001 12:21:10 GMT
Justin Erenkrantz <jerenkrantz@ebuilt.com> writes:

> Can someone enlighten me as to why we have --with-pthread-cross and we
> aren't telling anyone?  If we have pthread.h, PTHREAD_PROCESS_SHARED,
> and pthread_mutexattr_setpshared, it seems reasonable enough to 
> define USE_PROC_PTHREAD_SERIALIZE to 1.  Or, are pthread_mutex_t not
> suitable for cross-process locks for some other reason that we have to
> have a manual override?
> 
> Unless someone says otherwise, I'll commit this tonight/tomorrow.  

Please don't commit just yet.

That piece of code decides not what kind of interprocess lock
mechanism APR *has* support for on the platform but what kind of
interprocess lock mechanism APR will *use* by default.

I suspect that you misunderstood what that code is doing... otherwise,
you'd try to explain why you want to change the [usual] default
mechanism from fcntl() to interprocess pthread mutex.

Let's back up now.  What is the problem you want to solve?

a) you really think we should default to interprocess pthread mutex
   whenever the platform supports it?  

   I don't feel too comfortable with that for several reasons

    i) the current APR code doesn't support all platforms which have
       interprocess pthread mutex support

       the current logic relies on mmap-ed /dev/zero for the shared
       memory where the mutex lives; this doesn't work everywhere

       This should be remedied, but with your patch we go downhill on
       some platforms.

   ii) it means we pick a different default lock depending upon
       whether or not we have thread support

  iii) historically, fcntl()-based locking is something that works
       pretty darn well overall across supported platforms.  There are 
       platform and config-specific situations where something else is 
       more appropriate, but historically it has been the safest bet
       for a system-independent default.

b) you don't like the way APR let's the builder tell APR "yes
   indeed it is okay to use interprocess pthread mutex by default"

c) something else

> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.321
> diff -u -r1.321 configure.in
> --- configure.in	2001/06/28 01:57:02	1.321
> +++ configure.in	2001/06/30 19:52:34
> @@ -955,7 +955,7 @@
>  APR_IFALLYES(header:fcntl.h define:F_SETLK,
>              APR_DECIDE(USE_FCNTL_SERIALIZE, [SVR4-style fcntl()]))
>  APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
> -            func:pthread_mutexattr_setpshared custom:with_pthread_cross,
> +            func:pthread_mutexattr_setpshared,
>              APR_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex]))
>  if test "x$apr_lock_method" != "x"; then
>      APR_DECISION_FORCE($apr_lock_method)

(Sorry for the delay... We've been moving over the last week and
things are pretty crazy.)

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message