mneerach@b.inf.ethz.ch (Matthias Ulrich Neeracher) (08/02/90)
This week I tried to write an INIT (I did some before). Every time I tested it, it crashed. Stepping through my debugger, I found out that my INIT was unlocked and on return from a trap had been moved away. No problem... I just set the lock bit on the INIT resource and everything worked as expected. Still, I'm curious: After all, the System locks most resources before calling them: CODE, WDEF, MDEF, CDEF, snth and probably even cdev resources. Why are INIT's not locked by INIT31 ? Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
austing@Apple.COM (Glenn L. Austin) (08/08/90)
mneerach@b.inf.ethz.ch (Matthias Ulrich Neeracher) writes: >This week I tried to write an INIT (I did some before). Every time I tested >it, it crashed. Stepping through my debugger, I found out that my INIT was >unlocked and on return from a trap had been moved away. No problem... I just >set the lock bit on the INIT resource and everything worked as expected. >Still, I'm curious: After all, the System locks most resources before >calling them: CODE, WDEF, MDEF, CDEF, snth and probably even cdev resources. >Why are INIT's not locked by INIT31 ? They just aren't. Don't ask me why (one version of System Software actually DID lock it down, but it is "history" now, and was actually a "feature"). -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/09/90)
As to why the system doesn't lock INITs before executing them: What happens if the INIT wants to stay in memory after execution? Some people may load resident code by creating a new non-resource block and copying the code to there, but others could just do a DetachResource on the INIT, and leave it locked. There's no good way that I can think of that the system can allow for the possibility of a DetachResource call while handling the locking/unlocking of the INIT code itself. You could do a Resource Manager call (for example, a dummy LoadResource) to check if the handle is still a resource handle, but the time overhead to do this with every INIT is probably too much. The code that executes FKEYs, just as a contrasting example, does lock the resource down before execution, and unlocks it after. Nobody expects an FKEY to install itself permanently in memory after execution... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 If God's handiwork is so good, why doesn't she give a warranty?
mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher) (08/09/90)
In article <1195.26c1b5c3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >What happens if the INIT wants to stay in memory after execution? >Some people may load resident code by creating a new non-resource block >and copying the code to there, but others could just do a DetachResource >on the INIT, and leave it locked. There's no good way that I can think >of that the system can allow for the possibility of a DetachResource >call while handling the locking/unlocking of the INIT code itself. I disagree. All the System would have to do is to LOCK the resource and to close the file after having called all the INITs. Detached blocks will stay around, resources will get released. Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
russotto@eng.umd.edu (Matthew T. Russotto) (08/09/90)
In article <1195.26c1b5c3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >As to why the system doesn't lock INITs before executing them: > >What happens if the INIT wants to stay in memory after execution? >Some people may load resident code by creating a new non-resource block >and copying the code to there, but others could just do a DetachResource >on the INIT, and leave it locked. There's no good way that I can think >of that the system can allow for the possibility of a DetachResource >call while handling the locking/unlocking of the INIT code itself. >You could do a Resource Manager call (for example, a dummy LoadResource) >to check if the handle is still a resource handle, but the time >overhead to do this with every INIT is probably too much. Actually, the system wouldn't need to unlock the INIT-- it can just do as it does now and close the resource file. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/10/90)
Two separate people have pointed out that the system doesn't need to unlock INIT resources, it just has to close the resource file and all the resource handles will disappear. Sounds good. But what about the case where an INIT file contains more than one INIT resource? I think Apple wants to avoid being accused of using memory carelessly, and boot-time system heap space is particularly precious. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 People suffering from kleptomania should be able to take something.
tim@efi.com (Tim Maroney) (08/11/90)
In article <1195.26c1b5c3@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >As to why the system doesn't lock INITs before executing them: >What happens if the INIT wants to stay in memory after execution? >Some people may load resident code by creating a new non-resource block >and copying the code to there, but others could just do a DetachResource >on the INIT, and leave it locked. There's no good way that I can think >of that the system can allow for the possibility of a DetachResource >call while handling the locking/unlocking of the INIT code itself. Why should the system bother to unlock a resource from an INIT file? The resource will go away when the file is closed anyway. If INIT 31 just locked INITs on entry and didn't unlock them when they return, everything would be fine.
mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher) (08/13/90)
In article <1202.26c2f147@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Two separate people have pointed out that the system doesn't need to >unlock INIT resources, it just has to close the resource file and >all the resource handles will disappear. > >Sounds good. But what about the case where an INIT file contains more >than one INIT resource? I think Apple wants to avoid being accused of >using memory carelessly, and boot-time system heap space is particularly >precious. But what is the current way to deal with locking ? a) Set the lock bit of the INIT resource when creating it. This will leave the resource around locked, just the same. b) Lock and unlock it yourself. This will also work if the System locks the resource first, unless you use HGetState/HSetState instead of HUnlock. Also, INITs are by default loaded into the application heap, not the system heap (Correct me if I'm wrong). Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson