On Thu, 27 Dec 2001 15:53:44 -0800, Aaron Bannert wrote: >On Fri, Dec 28, 2001 at 10:47:53AM +1000, Brian Havard wrote: >> On Thu, 27 Dec 2001 15:15:54 -0800, Aaron Bannert wrote: >... >> >A problem with this is that it introduces a second way to return a >> >status from an exiting thread. >> >> What's wrong with that? Both ways are already available so they should both >> have the same type. It's a very simple change. > >I would agree, I'd just rather not have two ways of doing the same thing. It >means we'll have to maintain it in two places, and it'll confuse people >using our lib.
It's no different than having both "return from main()" & exit() at the process level. >> > One reason we need apr_thread_exit is >> >so that we can exit the thread without falling all the way back to the >> >initially called apr_thread_start_t function. >> >> >Another reason* why we need apr_thread_exit that I just relized is that >> >it destroys the thread's pool. If the thread exits w/o calling >> >apr_thread_exit then it is leaking memory. >> > >> >-aaron >> > >> >*I'll rush off and check all apr_thread_create's to make sure they >> >have all the apr_thread_exit()s that they need. >> >> It'd be better to just make dummy_worker() do an apr_pool_destroy() before >> returning. That prevents the leak while still allowing return to be used. > >I see no problem with that. Better yet, dummy_worker() could call >apr_thread_exit() itself, since you'll never make it back into the return >clause of dummy_worker() if you already called apr_thread_exit(). Sure. >Still, >I'm -0 on introducing two ways to do the same thing. It's not introducing anything. Both ways already exist & we can't take either away so they may as well be consistent. -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------
