From dev-return-5241-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Dec 28 00:04:07 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 47422 invoked by uid 500); 28 Dec 2001 00:04:07 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 47410 invoked from network); 28 Dec 2001 00:04:05 -0000 From: "Brian Havard" To: "APR developers" Date: Fri, 28 Dec 2001 11:04:11 +1000 (EST) Reply-To: "Brian Havard" Priority: Normal X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05 In-Reply-To: <20011227155344.A1529@clove.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: apr/test testthread.c Message-Id: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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! | | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------