From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8acf684047f1930df45bba2b9208ea3e@quanstro.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Google search of the day From: erik quanstrom Date: Fri, 15 Feb 2008 08:15:05 -0500 In-Reply-To: <47B4A1C6.4208D94C@null.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 54ab6df2-ead3-11e9-9d60-3106f5b1d025 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.