apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Pools rewrite [2]
Date Wed, 05 Dec 2001 18:14:20 GMT
On Wed, Dec 05, 2001 at 06:06:28PM +0100, Sander Striker wrote:
> > 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.

That's fine, it's up to you. If it bothers me enough to change it I'll
post a patch. :) We're going to have to add some more stuff in there
anyway (like a return for status or something) which wouldn't make sense
to have in a macro. Justification follows...

> [...]
> > > 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?

I'm suggesting that either you protect the apr_thread_once call in #ifdef's,
or we write an apr_thread_once that works regardless of if APR_HAS_THREADS
is defined.

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

No, it'll be something like this:

    /* do stuff to prevent deadlocks on threaded builds, like: */
    /* I can't imagine what you'd need to do special to treat the
     * non-threaded case, so the "#else" case probably won't exist. */

Pools don't need cross-process locks, right? In any case, the new lock
api is supposed to be a full replacement for the old one.


View raw message