Richard Gooch wrote:
> Because it's different (read harder)? I still haven't seen a
> description of how we handle stack exhaustion properly. All we can do
> there is kill the offending process.
>
--- Naw....we have lots of options. The first and best 1) A gram of prevention is worth a kilogram of cure. If the developer or user knows that a given program uses alot of stack space, then an option in 'ld' to specify size of stack to commit, or 2) User says "runprog -stacksize=1M <programname>" or some such option -- and 1M of stack space is committed/reserved before when loading the program. 3) We use a signal -- I sorta like overuse of SIGSTKFLT, but there may be reasons not to use it. If in default, program dies as from a SEGV, and 4) if ignored, program is put to sleep waiting on free pages.Ok, maybe that wasn't lots, but it was at least 4! :-)
Not to sound repetitious, but why is lack of memory (a resource as David puts it) so different from #processes, #open files/system /process, out of diskspace on a write call, unable to acquire a 'lock' resource...
Those just return error's or 'sleep'. Why should we come up with a new paradigm for memory?
-l
Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:18 EST