apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Pools in threads WAS Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Sun, 15 Jul 2001 23:46:00 GMT
On Sun, Jul 15, 2001 at 02:33:54PM -0700, rbb@covalent.net wrote:
> Guys, before you make comments like this, you should really read the code.
> First of all, the thread_exit call needs to take in the thread variable.
> Without it, platforms like OS/2 can't return values from the thread exit
> routine.

We could stipulate in APR that on OS/2 we won't return the result 
code.  Big deal.  It's not the end of the world.  And, it's only a hack
that works in conjunction with OS/2's apr_thread_join.  OS/2 threads
obviously don't support return codes.  APR is only as good as the
underlying thread library.

BeOS, Unix (pthread), and Win32 don't need the thread structure to 
destroy the thread or return the result code.  That seems to be the 
consensus on how threads should operate.  

If you are willing to lose the return code on OS/2, you now have OS/2 
not needing the thread structure either.  APR is a game of tradeoffs - 
this is one we should make in order to get a better API at the cost of 
something that this native OS doesn't provide anyway.

We should be seeing red flags everywhere because our own code isn't
calling the apr_thread_exit() function.  Why?  The API is, uh, 
lacking.

> Secondly, as long as the thread has access to the apr_thread_t, it also
> has access to the pool within that value.

Well, I disagree that the thread should have access to its underlying
apr_thread_t.  It's a very awkward thing to do.  Doable?  Certainly.
Clean?  No.  You now need a pointer into the thread array (or
linked-list if that is how you do it - almost all places do it now with
arrays) passed to the worker function.  Gag.

And, once a thread is spawned, it is now on its own for memory.  So, 
it should create a SMS independent of any other SMS.  That's the goal 
and driving force behind SMS - we need a per-thread SMS.

There is *zero* benefit to having any relationship between the 
thread's memory pool and the parent's memory pool.  You can't cleanup 
the thread from the parent anyway, so trust the thread to cleanup 
itself (as well as its pool and any memory allocations).  I fail to 
see the problem here.  Sever the imagined relationship.  The code 
becomes simpler, too.  -- justin


Mime
View raw message