Aaron Bannert <[EMAIL PROTECTED]> writes:
> 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?
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 :)
> 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().
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
