On 8/22/05, Nick Kew <[EMAIL PROTECTED]> wrote: > On Saturday 20 August 2005 23:33, Jeff Trawick wrote: > > On 8/20/05, Nick Kew <[EMAIL PROTECTED]> 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
