On Sun, 26 Mar 2000, Linda Walsh wrote:
>Richard Gooch wrote:
>> 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,
This does not work in general. In order to protect any given process, you
have to fix the stack allocation of ALL processes, not just the one you
care about. And what do you do in the case of recursion, when you don't
know in advance the number of times you will recurse?
This is also another example of solving the problem by defining all
current software to be broken.
>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.
Same problem as before...
> 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,
Why not just keep overcommit, have malloc() always succeed, and then use a
signal anyway when memory is low? Unfortunately Linux doesn't have any
spare signals lying around -- especially if you use threads (linuxthreads
uses SIGUSR1 and SIGUSR2).
4) if ignored, program is put to sleep waiting on free pages.
This leads to a deadlock.
> 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...
Read my previous mail for some reasons.
Dave
David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
-
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