Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
From: Nick Kew <nick@webthing.com>
Organization: WebThing Ltd
To: dev@apr.apache.org
Subject: Re: Reducing #ifdef burden on APR applications
Date: Thu, 25 Aug 2005 14:48:14 +0100
User-Agent: KMail/1.8.1
References: <43071434.8070802@webthing.com> <430C4B43.5020401@webthing.com>
 <20050824104952.GB9985@redhat.com>
In-Reply-To: <20050824104952.GB9985@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200508251448.17996.nick@webthing.com>

On Wednesday 24 August 2005 11:49, Joe Orton wrote:

> > No, I still disagree.  The fundamental point is that it leaves us using
> > ENOTIMPL in a manner that is both success (it's a no-op) and failure
> > (it's not implemented because noone got round to it yet).  I want my
> > applications to know when they're dealing with an error!
>
> Nick, I think the disconnect here is that you are talking specifically
> about making thread mutex locking functions (and maybe condvars, rwlocks
> etc?) return APR_SUCCESS on error, right?

Indeed, it's only a small subset of ops for which NOOP is in fact
equivalent to success.  Areas like thread create or run, reslist, etc
are either fully implemented or it's an error for which ENOTIMPL
is entirely appropriate.

> The argument being that in absence of threads, the locking across
> threads can legitimately do nothing and return SUCCESS since there are
> no threads to lock between.  This seems quite tempting, but I do find
> Jeff's horror story pretty scary w.r.t. the Solaris equivalent.

I remain to be convinced about that, but I accept we might like a distinction
- hence my suggestion of APR_NOOP for such cases.

But we now also have Philip Martin's point that returning SUCCESS is in
line with glibc on Linux.  Evidently this is common practice in real life!

> But for the general case, e.g. apr_thread_create() and really
> apr_thread_* in apr_thread_proc.h, it would just be a gross API
> violation to have the functions return SUCCESS for a !threads build, do
> you agree?

Of course!  No argument about that.

-- 
Nick Kew