[lkml]   [1997]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Memory overcommitting
At 21:20 -0500 2/19/97, Sean Farley wrote:
>Let's say that you wrote an application that must have control over any
>demise of the application, i.e. database. Since we cannot make the
>assumption that malloc will protect us from ourselves or another ruthless
>program, what course should someone take to handle a more graceful
>shutdown if the situation comes about? How does Linux kill off processes
>when the memory is exhausted?

One strategy for such mission-critical apps would be to grab a sizable
chunk of memory at initialization time as your emergency "cushion". Then
install a signal handler for SEGV which:
- releases the cushion, curing the memory shortage for the short term
- shuts down your app

- sends your app into a special emergency shutdown which performs
any cleanup routines using the memory inside your cushion

The first plan has the disadvantage that other processes may steal the
released cushion memory, leaving you without enough to clean up with.


PS - Of course, holding a large chunk of memory for the lifetime of the
process without ever using it is exactly the kind of thing that would
result in an overcommitted memory situation in the first place ;-)

Vance Huntley

Director of Technology (& Chat Guy)
WebGenesis, Inc., Ithaca, NY 14850 --- 607.255.8499

Check out "The Globe"! ---

 \ /
  Last update: 2005-03-22 13:39    [W:0.061 / U:1.644 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site