Xref: news2.mv.net comp.os.msdos.djgpp:5910
From: brucef AT central DOT co DOT nz (Bruce Foley)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking RAM for hardware interrupts
Date: Fri, 12 Jul 1996 10:46:39 GMT
Organization: Internet Company of New Zealand
Lines: 25
Message-ID: <4s5dmj$bvj@status.gen.nz>
References: <836949496 DOT 23711 DOT 0 AT abwillms DOT demon DOT co DOT uk> <31e3b1df DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host: brucef.central.co.nz
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:

>Certainly locking everything (or just all code) is easier and safer than
>doing it a routine at a time.  But this will cause bad paging performance
>on systems with insufficient memory (or an outright failure with a 
>pagefault if there isn't enough memory to lock).  If you are willing to
>put a bigger minimum ram requirement to run your program, that's fine,
>but locking only the routines needed would allow the code to potentially
>run on a 1Mb box.

Hi. I'm fairly new to DPMI and this thread interests me.  I have been
studying the ALLEGRO library (a fantastic resource) and I notice that
"critical" code and data are locked via function calls.  When you 
refer to paging, I assume you mean the potential of memory to be
swapped out to disk, creating a larger amount of virtual memory
than is actually available, yes?  If this is the case, then I imagine
that any data (or code) associated with an ISR would cause
a system crash if the interrupt was generated after the page had
been swaped out (and was hence unavailable).  Is this right?
Or am I totally off-track.

Regards,  Bruce.