apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Reducing #ifdef burden on APR applications
Date Mon, 22 Aug 2005 11:13:25 GMT
On Mon, Aug 22, 2005 at 11:43:12AM +0100, Nick Kew wrote:
> On Saturday 20 August 2005 23:33, Jeff Trawick wrote:
> > On 8/20/05, Nick Kew <nick@webthing.com> wrote:
> > > Jeff Trawick wrote:
> > > > If APR always provides such APIs and acts like they work, what is to
> > > > signal to a threaded APR app that they are picking up a non-threaded
> > > > libapr?
> > >
> > > With reference to anything in particular?  Surely you wouldn't use
> > > apr_thread_mutex unless you were using apr_threads?  Doesn't that
> > > principle extend to other applications?
> >
> > perhaps I'm a library that needs to be thread-safe, and I'm called by
> > a threaded app but find a non-thread-capable apr at load time?  (too
> > far fetched)
> 
> OK, I guess what we really want here is an additional return code APR_NOOP.
> NOTIMPL is inappropriate, and you've raised an objection to SUCCESS.

Why is ENOTIMPL inappropriate?  The function is not implemented for the 
non-threaded build.  If you want to be able to use these functions 
unconditionally then you have to check for SUCCESS or (something) and 
(something) may as well be APR_ENOTIMPL as some new code.

What's really needed is a feature-detection API along with the ENOTIMPL 
stubs.

  if (apr_has_feature(APR_FEATURE_THREADS))
    /* create mutex */

though there will be some subset of the API for which run-time detection 
is infeasible e.g. apr_portable.h, IPv6-ness.

joe

Mime
View raw message