apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Date Mon, 02 Jul 2001 15:27:21 GMT
On Mon, Jul 02, 2001 at 08:21:10AM -0400, Jeff Trawick wrote:
> Please don't commit just yet.

Should I back this out?  Ryan wants to T&R at 10AM PST.  I guess the
easy "fix" would be to place fcntl() decision AFTER the 
pthread_mutex_t support.

> 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.

Correct, I knew that.  But, as seen by the other warning that was 
triggered by this, no one actually has ever tested/maintained this code.
Now, we can start to exercise it.  =-)  (Which is partly the reason why
I was complaining about the 2.0.20 T&R taking in these changes...)

> 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.

Typically, from my understanding of things, pthread mutex should be 
the option that lets us scale the best on the high-end.  From what 
Bill said, this is what IBM ships with IBM HTTPD.  And, on Solaris, 
you want to use pthread-related locking for best performance.  Now, I 
could be wrong about this being the "best choice."

> 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.

What platforms are going to have pthread_mutex_t with SHARED_PROCESS
that WORKS and not have this?  By process of elimination, I'll think
we'll find that this won't be a big deal.  <smirk>  Yeah, we can
address that somehow.  Now, we need to somehow get shmem working.

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

Lots of things change if you have thread support or don't.  IF this is
truly the better option if you are going to have threading, why not
enable it?

>   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.

Yes, but is fcntl() the "best" choice?  -- justin

View raw message