apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Reducing #ifdef burden on APR applications
Date Wed, 24 Aug 2005 10:49:52 GMT
On Wed, Aug 24, 2005 at 11:26:11AM +0100, Nick Kew wrote:
> Justin Erenkrantz wrote:
> >--On August 22, 2005 1:35:48 PM +0100 Nick Kew <nick@webthing.com> wrote:
> >
> >>I disagree.  For example, APR_EOF is an end-condition, not an error.
> >>apr_errno even defines different ranges of codes for different things.
> >>
> >>In practical terms, suppose I implement APR for Platform X, but leave
> >>some parts (which my application doesn't happen to need)
> >>unimplemented, returning APR_ENOTIMPL.  Now if we've used APR_ENOTIMPL
> >>for a no-op success, *all apps* that use the feature have lost the
> >>distinction between success and a failure that can't be ignored.
> >
> >
> >Not true.  The application can then decide what to do in the presence of 
> >the APR_ENOTIMPL case - in this case, we can document that apr_thread_* 
> >foo can return APR_ENOTIMPL if the underlying OS doesn't support it.
> 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?

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.

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?



View raw message