gjs@k.cs.cmu.edu (Gregory Stein) (06/04/86)
Keywords: In an article from <oster@ucblapis>, he writes: > Therefore, it is very important to lock handles when you need them locked, > and unlock them again as soon as possible. Segmentation changes the rules > for when things need to be locked. True, segments are loaded into memory and then locked. While developing Rascal, this caused many problems since we wanted Rascal to run on a 128K Mac. Our solution was to patch the _LoadSeg trap. When the trap was executed, our routine would do a GetResource to get the CODE segment, call MoveHHi to move it up to the top of memory, lock it, and then continue on to the ROM _LoadSeg routine (address found in the trap table before we changed it). When the ROM _LoadSeg routine did a GetResource, it received the handle of the already locked resource. This would cause all of our segments to be pushed up to the top of memory. This was fine until we also figured out that holes would open up if a segment was unloaded and purged. This purge would usually happened from loading another, smaller segment over the top. Therefore, when employing this trick, you must make sure that if a segment loads another, the second segment must be unloaded before the first. Drawing a tree structure of the segments and which ones load which others helps very much. (But it got very complex once there was 20+ code segments). Greg Stein gjs@k.cs.cmu.edu