At 03:05 PM 3/1/2004, [EMAIL PROTECTED] wrote:
trawick 2004/03/01 13:05:44
Add apr_threadattr_stacksize_set() for overriding the default stack size for threads created by apr_thread_create().
Tell us - does this really scale?
If you mean "is this a perfect abstract model" then of course the answer is no. It is not even an abstract model at all, as you point out below. It is simply a knob, required in order for some apps to be apr apps because of the way thread stacks are usually handled (a fixed amount set at thread creation time).
Can an arbitrary value, e.g. 128k, have any relationship between 32bit and 64bit platforms, or those with significantly different register pus/pop lists?
wink
It seems this might make the platform less transparent, contrary
to apr's purpose. It seems like passing some value such as stack
words (32/64 bit quantities) and or stack call depth hints might be more consistent to use. Comments/ideas?
This seems pretty difficult since as far as the stack is concerned my poor little app/Apache module/whatever is really my piece of code + apr apr-util libc Berkeley db FOO-client-library etc. etc. etc. What could I expect the providers of all those other libraries to give me? The characteristics of the call trees that I actually use in the library? Worst-case requirements based on overall library capabilities? What if the requirements are different for different platforms? I just don't see being able to determine abstract characteristics except for relatively small pieces of code. For the whole app? Too hard, even if all the library providers try to help. In the end? Bump it up to XXX and see if that is enough to fix the overflow. Or trim it down to YYY and see if that frees up some unnecessary heap storage.
