apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Thu, 02 Aug 2001 15:54:44 GMT
On Thu, Aug 02, 2001 at 11:16:46AM -0400, Jeff Trawick wrote:
> > I see your point. How about APR_UNDEFINED or APR_NOSTATUS?
> sounds reasonable to me
> > > Why would a "return NULL" instead of apr_thread_exit() imply exiting
> > > under error?  It depends upon the app.
> > 
> > I agree that it depends on the app, and I don't necessarily think that
> > return NULL implies an error, but intuitively it doesn't imply success.
> > Aren't there compilers out there that will let you return from a non-void
> > function w/o giving a return value? What would happen then?
> It is an application bug regardless of the compiler (which will
> probably complain).  I don't think this is a type of application bug
> which should have any bearing on APR design :)

I'm sure this has come up in general discussions before about how much
error checking/handling APR should be doing (and the answer was "none");
but other than documenting the interface, is there anythin APR should
try to do to identify this application bug?

> > It's actually a really bad thing to not use apr_thread_exit() to end a
> > thread. That is the only way APR can destroy the thread's child-pool.
> > Maybe the way to enforce this is to check if the thread was able
> > to return directly, and then make sure it gets destroyed.
> Instead of thinking of it as a really bad thing not to use
> apr_thread_exit() I'd just say that we have missed some required logic
> in dummy_worker().  Heck, perhaps dummy_worker() can call
> apr_thread_exit().

That's not a bad idea. If APR threads can only really return a status,
there is no real use for apr_thread_exit() (as long as we have the
dummy_worker() wrapping the call to the real thread worker fn). In
that case I think we should just get rid of it entirely and simply have
the return value be apr_status_t. That way we don't have to fool with


View raw message