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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
