POV-Ray : Newsgroups : povray.beta-test : max_trace_level problem : Re: max_trace_level problem Server Time
30 Jul 2024 18:24:15 EDT (-0400)
  Re: max_trace_level problem  
From: Ron Parker
Date: 12 Nov 2001 08:44:35
Message: <slrn9uvki8.3l1.ron.parker@fwi.com>
On 12 Nov 2001 06:56:23 -0500, Warp wrote:
> 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).

Nope, a Win32 stack has a "reserve" size and a "commit" size.  The loader 
allocates address space for the "reserve" size, but it only actually maps
memory for the "commit" size.  It then marks the page just below the 
commit as Not Present and waits for it to fault.  When it faults, the OS
maps another page into the address space.  (Theoretically, it's possible 
to blow up an app by decrementing the stack pointer by more than a page.)

This is the reason for the maximum size: it's not a matter of allocated
memory, but of allocated address space.  The stack has to be contiguous.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.