Xref:	news-dnh.mv.net comp.os.msdos.djgpp:3737
Path:	news-dnh.mv.net!mv!news.sprintlink.net!newsfeed.internetmci.com!in1.uu.net!EU.net!peer-news.britain.eu.net!yama.mcc.ac.uk!news.york.ac.uk!tower.york.ac.uk!slh100
From:	Shawn Hargreaves <slh100 AT york DOT ac DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Memory locking woes
Date:	Sat, 9 Dec 1995 18:02:50 +0000
Organization:	The University of York, UK
Lines:	23
Nntp-Posting-Host:	tower.york.ac.uk
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

I've been struggling with page locking using djgpp v2. My program traps a 
lot of interrupts, and calls a lot of C library routines from these 
interrupts, so there is no easy way to figure out exactly what memory 
needs to be locked. I decided that I would just lock everything, which 
is an ok solution, since I do my own loading and discarding of data, 
rather than relying on dpmi to provide virtual memory). Unfortunately 
things turn out not to be as simple as this. The sbrk() routine in crt0.s 
uses dpmi functions to enlarge the block of memory that my program is 
using, which can change the segment base address, thus messing up all my 
memory locking! It would be a terrible pain to have to relock everything 
after each call to malloc()...

To get around this I have patched crt0.s to lock the memory as it 
allocates it, but this is a very ugly solution since there is no way to 
only lock certain parts of memory. It would be nice if the v2 libs could 
provide some more intelligent page locking routines, that would take 
care of re-locking memory if sbrk() alters my base address. Are there 
any plans for such a thing? If not I would be happy to do some work on it...


Shawn Hargreaves                        If God is omnipotent, can he make a
http://www.york.ac.uk/~slh100/          rock so heavy that he cannot lift it?

- Raw text -