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 Sat, 20 Aug 2005 14:29:55 GMT
On 8/20/05, Nick Kew <nick@webthing.com> 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 dev@httpd 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?

Mime
View raw message