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). 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() -aaron
