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. BeOS, Unix (pthread), and Win32 don't need the thread structure to destroy the thread or return the result code. That seems to be the consensus on how threads should operate. 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. 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. > 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. 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. 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
