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 APR_UNDEFINED/APR_NOSTATUS/whatever. -aaron
