apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Reducing #ifdef burden on APR applications
Date Mon, 22 Aug 2005 11:09:02 GMT
On 8/22/05, Nick Kew <nick@webthing.com> 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.
> 
> Of course that'll complicate the normal check-for-APR_SUCCESS code:-(

maybe do the APR_SUCCESS no-op flavor and give the app a way to query
if certain features are enabled; so an app could fail at startup if
there is no threads support but it doesn't want to run with such a
build of APR; querying feature set is independently useful

Mime
View raw message