Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!mcsun!cernvax!chx400!ethz!neptune!a!mneerach
From: mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why does the System not lock my INITs ?
Message-ID: <1716@neptune.inf.ethz.ch>
Date: 13 Aug 90 09:00:16 GMT
References: <157@neptune.inf.ethz.ch> <43741@apple.Apple.COM> <1195.26c1b5c3@waikato.ac.nz> <1202.26c2f147@waikato.ac.nz>
Sender: news@neptune.inf.ethz.ch
Reply-To: mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher)
Organization: Departement Informatik, ETH, Zurich
Lines: 26

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