Chris Cason <newsadmin-despam-@povray-no-spam.org> wrote:
: Win32 behaves exactly as it should - it dynamically grows the stack as it's
: needed.
: The default stack size (as given in the EXE) is merely the maximum
: stack size, not the initial size.

  Ok, then it's better than I thought.
  I had the impression that programs allocate a stack for themselves with just
a regular memory allocation call. Thus the stack will always take the same
amount of memory and its size would be fixed. This would mean that one has to
always find a compromise between stack size and memory usage (ie. it's a waste
of space to reserve a 100MB stack if you are just going to use 1KB of it).

  However, if it's just a maximum size, not a fixed size to be allocated, as
you say, then I don't see any problem in increasing it considerably. If more
memory is not consumed even if a 100MB maximum stack size is specified, then
I don't see any problem in doing this.

: Put another way, POVWIN has a maximum stack size of 1mb per thread, currently,
: as I have to date seen no compelling reason to change this.

  Increasing the possible max_trace_level is a very good reason in my opinion.
People wouldn't have found this limitation (what is it? something like 300?)
if they never would need it.
  Increasing the maximum stack size to 100 times the current should be enough
for everyone. (Yes, pun intended.)
  A max_trace_level limit of about 30000 is very acceptable in my opinion.
Just add to the documentation a visible note that using a bigger
max_trace_level can use lots of memory.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message