apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Pools in threads WAS Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Mon, 16 Jul 2001 02:20:28 GMT
On Sun, 15 Jul 2001, Justin Erenkrantz wrote:

> 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.

No, because that is utterly bogus.  The whole point of APR, is to allow a
program to be written that will work on ANY platform.  There are very few
features that can't be implemented cross platform.

> 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.

No.  APR is not a game of tradeoffs.  It has never been a game of
tradeoffs.  We only make decisions like this when it is absolutely
impossible to implement a feature on a given system.  As we have already
shown, this can be implemented.

> 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.

No, that is not why we don't call apr_thread_exit.  We don't call
apr_thread_exit, because we don't need it.  There are two ways for threads
to terminate.  1)  Call apr_thread_exit.  2)  return from the function
that was started when the thread was created.  We happen to use option 2,
because it fits our model better.  Do not misinterpret a choice for a
flaw.  Even before the APR threading code was written, there was a hybrid
thread/process version of Apache.  Versions of this can be found in the
apache-apr repository.  That original hybrid Apache did not EVER call
pthread_exit().  This was a conscious choice made by myself, Bill
Stoddard, and Manoj Kasichainula.

> > 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.

So it has been implemented poorly.  That doesn't mean anything.  A poor
implementation is very often where things begin.  It is relatively simple
to fix the implementation.

> 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.

SMS has nothing to do with threads.  I made a mistake when I wrote APR.  I
tied it to pools.  But pools don't work for all apps.  They happen to work
really well for the web server, but most apps don't have memory profiles
like a web server.  The idea of an SMS-like memory allocator was discussed
years ago, and the idea was to make APR useful outside of the web server.

> 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

Pools are by their very nature hierarchical.  That is why the relationship
is there, and why it needs to remain there.  You can't just rely on the
thread to cleanup itself.  Pools (and SMS's) are used for a LOT more than
just memory allocation in the server.  They make sure that descriptors are
closed correctly.  In some places, they are used to make sure that
anything the child opened that isn't returned to the OS automatically is
returned when the child goes away.

If you divorce the thread pool from the pool for the child, you WILL break
many assumptions in the server.


Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message