apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Sun, 15 Jul 2001 21:36:22 GMT
On Sun, 15 Jul 2001, Aaron Bannert wrote:

> On Sun, Jul 15, 2001 at 07:16:35PM +0200, Sander Striker wrote:
> > > Fair enough. It's just that in order to opt-out of the child-pool creating
> > > process in apr_thread_create, we're going to have to add a parameter
> >
> > Why are we so desperate in opting out the child-pool creation?
> > I don't really have problems with a child pool for each thread. Actually,
> > it will make the dynamic locking a lot easier to implement if it stays.
>
> 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.

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?

Ryan

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


Mime
View raw message