Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!wuarchive!uunet!aplcen!haven!ncifcrf!lhc!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why does the System not lock my INITs ?
Message-ID: <1990Aug9.162446.1107@eng.umd.edu>
Date: 9 Aug 90 16:24:46 GMT
References: <157@neptune.inf.ethz.ch> <43741@apple.Apple.COM> <1195.26c1b5c3@waikato.ac.nz>
Sender: news@eng.umd.edu (The News System)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 19

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!