On Mon, 17 Dec 2007, Martin Peach wrote:
The cpu signals an overflow whenever the stack space runs out (the program tries to access the stack beyond its boundaries)
With Pd, this is never what happens on its own. Instead, just before processing each message, a check of the count of nested message processings in made (messages sent that are still being processed, not counting those scheduled by [delay] and stuff).
Win16 would typically have a 512 byte limit for the stack. This is too little for today's needs, but it could be increased up to 64k if you really wanted. In contrast, Linux can typically grow the stack to 512 megs or more, and I don't see why Win32 wouldn't be able to (though I have idea what Win32 does about it -- it probably has a reasonable stack size). 512 megs is too much for the protection that Pd needs.
Older versions of Pd checked stack size instead, but it was a problem with large on-stack allocations. What Linux (or OSX) does when reaching maximum stack size (which you can intentionally lower) is raise a signal, using kill(). It normally doesn't give you any sane way of handling this, so this is why applications that want to stay alive after a so-called stack overflow have to do it themselves and never involve the OS in it.
(If you want to escape an OS-based stack overflow, you can, you need to do things dependent on both which OS and which CPU type, and I wouldn't be surprised if it also depended on which kernel version. I never actually did it, but I'm pretty sure that it's doable, just that it's too scary).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada