On Sun, 15 Jul 2001, Justin Erenkrantz wrote: > On Sun, Jul 15, 2001 at 02:33:54PM -0700, [EMAIL PROTECTED] wrote: > > Guys, before you make comments like this, you should really read the code. > > First of all, the thread_exit call needs to take in the thread variable. > > Without it, platforms like OS/2 can't return values from the thread exit > > routine. > > We could stipulate in APR that on OS/2 we won't return the result > code. Big deal. It's not the end of the world. And, it's only a hack > that works in conjunction with OS/2's apr_thread_join. OS/2 threads > obviously don't support return codes. APR is only as good as the > underlying thread library.
No, because that is utterly bogus. The whole point of APR, is to allow a program to be written that will work on ANY platform. There are very few features that can't be implemented cross platform. > If you are willing to lose the return code on OS/2, you now have OS/2 > not needing the thread structure either. APR is a game of tradeoffs - > this is one we should make in order to get a better API at the cost of > something that this native OS doesn't provide anyway. No. APR is not a game of tradeoffs. It has never been a game of tradeoffs. We only make decisions like this when it is absolutely impossible to implement a feature on a given system. As we have already shown, this can be implemented. > We should be seeing red flags everywhere because our own code isn't > calling the apr_thread_exit() function. Why? The API is, uh, > lacking. No, that is not why we don't call apr_thread_exit. We don't call apr_thread_exit, because we don't need it. There are two ways for threads to terminate. 1) Call apr_thread_exit. 2) return from the function that was started when the thread was created. We happen to use option 2, because it fits our model better. Do not misinterpret a choice for a flaw. Even before the APR threading code was written, there was a hybrid thread/process version of Apache. Versions of this can be found in the apache-apr repository. That original hybrid Apache did not EVER call pthread_exit(). This was a conscious choice made by myself, Bill Stoddard, and Manoj Kasichainula. > > Secondly, as long as the thread has access to the apr_thread_t, it also > > has access to the pool within that value. > > Well, I disagree that the thread should have access to its underlying > apr_thread_t. It's a very awkward thing to do. Doable? Certainly. > Clean? No. You now need a pointer into the thread array (or > linked-list if that is how you do it - almost all places do it now with > arrays) passed to the worker function. Gag. So it has been implemented poorly. That doesn't mean anything. A poor implementation is very often where things begin. It is relatively simple to fix the implementation. > And, once a thread is spawned, it is now on its own for memory. So, > it should create a SMS independent of any other SMS. That's the goal > and driving force behind SMS - we need a per-thread SMS. SMS has nothing to do with threads. I made a mistake when I wrote APR. I tied it to pools. But pools don't work for all apps. They happen to work really well for the web server, but most apps don't have memory profiles like a web server. The idea of an SMS-like memory allocator was discussed years ago, and the idea was to make APR useful outside of the web server. > There is *zero* benefit to having any relationship between the > thread's memory pool and the parent's memory pool. You can't cleanup > the thread from the parent anyway, so trust the thread to cleanup > itself (as well as its pool and any memory allocations). I fail to > see the problem here. Sever the imagined relationship. The code > becomes simpler, too. -- justin Pools are by their very nature hierarchical. That is why the relationship is there, and why it needs to remain there. You can't just rely on the thread to cleanup itself. Pools (and SMS's) are used for a LOT more than just memory allocation in the server. They make sure that descriptors are closed correctly. In some places, they are used to make sure that anything the child opened that isn't returned to the OS automatically is returned when the child goes away. If you divorce the thread pool from the pool for the child, you WILL break many assumptions in the server. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
