apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Mon, 16 Jul 2001 06:44:21 GMT
> > I have some use cases that just want a thread. Since no child-pool is
> > required in this case, it becomes unnecessary overhead (that is currently
> > broken, as the child-pool is only cleaned in apr_thread_exit() but that
> > whole thing is screwey).
> Again, that is incorrect.  The THREAD-pool is cleaned whenever the parent
> pool is cleaned.  Yes, there is some extra overhead, but remember that the
> problem with pools (as the originally existed, and are still implemented
> in the server), is that you can't have two threads working with the same
> pool.

You are correct, I failed to mention that it is not *only* cleaned in
apr_thread_exit(), but also when the parent pool is cleaned. It is,
however, inappropriate to assume that the parent pool will ever get

Right now, if my application were to have a global/root pool that
repeatedly created short-lived threads (as it does, BTW), it would
eventually run out of memory. So, like I said, if apr_thread_exit()
is not called (and in all of apr, apr-util, and httpd is is never
called, not even in the test* programs), then that application is wholly
dependent on the ability of the thread's parent pool to clean up the

> IF SMS's replace all pools, then that might change.  As things stand
> today though, that hasn't happened, and may not happen quickly.
> > So if apr threads didn't know anything about child-pools, then they
> > would just simply create a thread that called my worker_function().
> > I could pass in my opaque data to that worker_function(), and do
> > the child-pool creations and destruction right there. I just don't see
> > how child-pool creation MUST be in apr_thread_create()
> Yes, you could do that, but then EVERYBODY who wanted to create a thread
> would have to do that, and why are we forcing people to duplicate that
> code everytime a thread is created?

I agree that this is a useful function *at some level*, and so I propose
that this particular utility be built on top of a lower-level set of APR
thread routines. I will even write these routines myself, just because
I believe they are useful.


View raw message