apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/threadproc/win32 thread.c
Date Tue, 02 Mar 2004 01:55:53 GMT
William A. Rowe, Jr. wrote:
> At 03:05 PM 3/1/2004, trawick@apache.org 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.


Mime
View raw message