Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of trawick@gmail.com designates
 64.233.162.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YMWR1o8E6RHhwEMZyPeWZujbKVucwEE92gGKQlUxQBCS2nwJeA1f6OF9RVeAcPJ+Wv47CQ05A3x518Hq04QvWAJzJaaThjpOpRN2V9bxzvwvV/IVbLbkYu3ryZBJ6pdBmPZnp4tuKgjp+3mPfWCkE92dyYFFXPJhiusH9ZkAmvs=
Message-ID: <cc67648e050820072942749964@mail.gmail.com>
Date: Sat, 20 Aug 2005 10:29:55 -0400
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Subject: Re: Reducing #ifdef burden on APR applications
In-Reply-To: <43073611.1000309@webthing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43071434.8070802@webthing.com>
 <20050820125919.GB14357@redhat.com>
	 <43073611.1000309@webthing.com>

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.
>=20
> 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?