> > 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 cleaned. 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 memory. > 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. -aaron
