apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Pools rewrite [2]
Date Wed, 05 Dec 2001 17:06:28 GMT
> From: Aaron Bannert [mailto:aaron@clove.org]
> Sent: 05 December 2001 17:32

> On Wed, Dec 05, 2001 at 12:35:00PM +0100, Sander Striker wrote:
> > > <comment>
> > > Ack.  No.  Declare a new scope like so:
> > > #define UNLOCK(mutex) \
> > >   do { \
> > >     if (mutex) \
> > >         apr_thread_mutex_unlock(mutex); \
> > >   } while(0)
> > > 
> > > Calling it like UNLOCK(mutex) (i.e. no semicolon) is just badness
> > > and will shoot us down the road later.
> > > </comment>
> > 
> > Ok, will change that.
> 
> If the semicolon is the only problem, just remove the semicolon from
> the macro:
> 
> #define UNLOCK(mutex) \
>     if (mutex) \
>         apr_thread_mutex_unlock(mutex)
> 
> 
> IMHO, I don't see the use of a macro for this kind of thing in the first
> place, because it's a simple enough construct. Also, we might want to check
> for errors on that lock call (up to you).

For one, use of this macro let me convert to the new locking api rather
quickly.

[...]
> > Isn't apr_thread_once restricted to platforms where we actually have
> > threads?  Hmmm, I now start to wonder about my apr_thread_mutex_xxx
> > calls.  Aaron?
> 
> apr_thread_once seems to be only usable on platforms where APR_HAS_THREADS
> is defined. On platforms where there are no threads, apr_thread_once
> can just be an int flag to make sure it doesn't get called twice.

Could someone provide a patch that works in both cases?

> As for the locking functions, the old way was that the locking routines
> were always available on platforms with thread support or not, but at
> runtime we'd get an APR_ENOTIMPL on platforms that didn't support it. If
> we run across a platform that doesn't support apr_thread_mutex_t right now,
> we'll at least get a compile-time error. Since that is undesirable, all
> uses of apr_thread_mutex_t should be protected in APR_HAS_THREADS #ifdefs.

Hmmm, so, actually we should use the old locking API (for cross process)
if !APR_HAS_THREADS and the apr_thread_mutex_xxx API when APR_HAS_THREADS?

> -aaron 

Sander


Mime
View raw message