apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr/test testthread.c
Date Thu, 27 Dec 2001 23:53:44 GMT
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.

> > 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(). Still,
I'm -0 on introducing two ways to do the same thing.


View raw message