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 Wed, 01 Aug 2001 23:40:48 GMT
On Wed, Aug 01, 2001 at 05:21:52PM -0400, Jeff Trawick wrote:
> Aaron Bannert <aaron@ebuilt.com> writes:
> > How about instead of assuming APR_SUCCESS we just leave it undefined?
> > This seems counter-intuitive, in that a worker function that prematurely
> > returns (w/o calling apr_thread_exit()) was probably exiting under error.
> What is an undefined apr_status_t?  An uninitialized apr_status_t?
> How does the caller of apr_thread_join() know it is undefined or
> defined?  "undefined" would have to be some APR error code.

I see your point. How about APR_UNDEFINED or APR_NOSTATUS?

> 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?

> An app is either going to have to code threads to always exit with a
> result or its code to join can't do anything useful with the thread
> status.

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.


View raw message