On Wed, Aug 01, 2001 at 05:21:52PM -0400, Jeff Trawick wrote: > Aaron Bannert <[EMAIL PROTECTED]> 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. -aaron
