On 8/20/05, Nick Kew <[EMAIL PROTECTED]> wrote: > Joe Orton wrote: > > On Sat, Aug 20, 2005 at 12:29:56PM +0100, Nick Kew wrote: > > > >>When writing APR applications, we sometimes need to make heavy > >>use of APR #ifdefs. > >> > >>A case in point is mod_dbd, which uses either apr_reslist or a > >>single persistent connection according to whether APR_HAS_THREADS. > >>As an APR application, this would be greatly simplified if > >>apr_reslist fell back to a trivial implementation of a single > >>resource in the non-threaded case, sparing the application > >>the burden of dealing with it.
apr_reslist seems like a good candidate to do the right thing when !APR_HAS_THREADS. > > and define > > ENOTIMPL stubs for everything in the !THREADS case. > > I think that needs to be APR_SUCCESS stubs for a null operation. > That's what apps test against, and there's no error condition! FWIW, here's a situation which I shall remember as long as I can remember my middle name: Solaris will link in APR_SUCCESS-style no-op pthread functions if your application isn't built thread-capable. Apache 1.3 was linked like this for a while. Some module code which actually used pthread functions was loaded and failed in bizarre ways. I couldn't believe that Solaris would do such a hokey thing. After much discussion between a security module vendor and a European bank and myself and a fortuitous discovery by a [EMAIL PROTECTED] lurker, it was resolved. 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?
