[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.018 / U:13.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site