Xref: news2.mv.net comp.os.msdos.djgpp:2054
From: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking Memory?...
Date: 22 Mar 1996 05:36:05 GMT
Organization: The National Capital FreeNet
Lines: 23
Sender: ao950 AT freenet6 DOT carleton DOT ca (Paul Derbyshire)
Message-ID: <4ite85$803@freenet-news.carleton.ca>
References: <4isq3j$s73 AT news DOT csus DOT edu>
Reply-To: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host: freenet6.carleton.ca
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp


Ralph A Pope (rpope AT saclink1 DOT csus DOT edu) writes:
> Basically, I want to know what is locking memory, what is done in the 
> procsess, side effects, pros and cons, etc.  because the Allegro library 
> uses it a LOT and I want to know how (and also find out if not being 
> locked is related to load_pcx not working a lot of the time :) ).
> 
> Any help you can give me would be GREATLY appreciated! :)

I believe locking memory means GO32 is told not to page a particular chunk
of memory out to disk, i.e. keep it in physical ram. This is needed if,
for instance, a callback is implemented with longjmp() that lands in the
affected area of memory, or if an interrupt routine is made to go there. (I
think.) Obvious side effects I can think of: more things in locked memory
means the program has to swap more for some tasks, slowing it down; and
obviously you can have all the HD space in the universe and still run out
of memory if huge gobs of it are locked.

--
    .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
 -()  <  circles, and bark is not smooth, nor does lightning travel in a
    `*'  straight line."    ,------------------------------------------------
         -- B. Mandelbrot  |  Paul Derbyshire (PGD) ao950 AT freenet DOT carleton DOT ca