believe it or not plan 9 does exactly the same thing, as was discussed in august under the subject "plan 9 overcommits memory?".
fundamentally, i think the stack problem is an operating system problem not a language problem. (unless you're talking about 8 or 16-bit embedded things.) the thread library, for example does just fine requiring its threads to declare a stack size. in the case of a memory-constrained app on an embedded system, the solution might be to find/write an algorithm that doesn't need a stack. :-) - erik > (1) Linux had/has a "feature" where the storage reserved by > malloc/sbrk may be over-committed, so that despite a "success" > indication from the allocation, when the application gets around > to using the storage it could suddenly fail due to there not > being enough to satisfay all current processes. I urged (but > don't know whether anybody listened) that overcommitment should > be disabled by default, with processes that want it (said to > include "sparse array" programs, which sounds like bad design > but that's another issue) being required to enable it by a > specific request, or at least flagged as special in the > executable object file. I kludged around this in my portable > malloc implementation by having a configuration flag which if > set caused malloc to attempt to touch every page before > reporting success, trapping SIGSEGV in order to maintain > control. > > (2) C, as well as many other PLs, has always had a problem in > that there is no clean, standard mechanism to handle the > situation in which a function invocation finds insufficient > stack remaining to complete the linkage (instance allocation). > This is especially problematic in memory-constrained apps such > as many embedded systems, when the algorithm is sufficiently > dynamic that it is impossible to predict the maximum nesting > depth. At least with malloc failure, the program is informed > when there is a problem and can take measures to cope with it. > > I hope people working on run-time environments will find ways > to do better.
