Re: [9fans] Google search of the day

[erik quanstrom <quanstro@quanstro.net>]

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.