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] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL
Date Tue, 03 Jul 2001 17:36:04 GMT
[ Dropping new-httpd as this has no current relevance to them ]

On Tue, Jul 03, 2001 at 09:25:26AM -0700, Aaron Bannert wrote:
> That would be useful if APR_HAS_THREADS was somehow set per the app's
> definition, not at APR's buildtime. I assume you're talking about this:
> 
>     case APR_PROCESS_SHARED:
>         if (new->inter_meth->flags & APR_PROCESS_LOCK_MECH_IS_GLOBAL) {
>             new->meth = new->inter_meth;  /* impl. uses one lock */
>         }
>         else {
>             new->meth = &lockall_methods; /* impl. uses two locks */
>         }
>         break;

When I looked at it this morning, I thought it didn't do what we want.
Now, that I went back to sleep and woke up again, it seems to do what we
want.  That is defined when we are either on OS/390 or we don't have
threads, which seems to be the correct definition.  And, I guess that
when we use pthread_mutex_t (which we think is broken) for
PROCESS_SHARED, it automatically gets the PROCESS_PRIVATE lock.

So, I guess that your patch as currently posted will do the right thing
(only one lock) if we don't have threads.  I wonder if this removes 
Jeff's objections?

> > This could give the non-threaded users of APR even more reason to 
> > specify "--without-threads" when configuring - which they should be 
> > doing in the first place.
> 
> yes. And we want recompiles of APR, no?

If you have a non-threaded app, you should use a non-threaded APR.
That's what makes sense to me, at least.  -- justin


Mime
View raw message