Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!imagen!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: Malloc (was Re: Another great quote from Mr. Good) Message-ID: <1125@atari.UUCP> Date: 19 Aug 88 17:53:15 GMT Article-I.D.: atari.1125 References: <1116@atari.UUCP} <692@auvax.UUCP} <1121@atari.UUCP> <6339@chinet.UUCP> <402@clio.math.lsa.umich.edu> Reply-To: apratt@atari.UUCP (Allan Pratt) Distribution: comp Organization: Atari (US) Corporation, Sunnyvale, California Lines: 65 I appreciate the recent wave of comments to the effect that "it doesn't make sense to have both allocators in the same system at the same time." What I believe is missing here is a general understanding of what the new Malloc (the one in the upcoming TOS 1.4 release) really does. The old Malloc (11/20 and Mega ROMs) used OSPool for memory descriptors, but used it VERY BADLY, and there was interference with the 40-folder bug (because folder descriptors also came out of OSPool). That's why there were limits on the number of blocks you could allocate, and the way you freed them. The new Malloc still uses OSPool because it can't use TPA: people mess with memory they don't own, and they expect successive Malloc's to return contiguous memory. But the OSPool has been GREATLY IMPROVED. Now it is managed correctly, with reasonable allocation and freeing and compaction and so on, and furthermore it can be extended (for the use of both folders and memory descriptors) by the same old FOLDR100.PRG. The likelihood of running into trouble with too many folders or Malloc is now MUCH REDUCED, and the fix is easy: use FOLDR100.PRG. Importantly, you no longer get mysterious behavior when you really do run out of pool: Malloc now returns zero, and folder allocations simply fail (you get a message on your screen and the system dies, but I consider that better than mysterious and data-losing behavior). Before you clamour about "The 40-folder bug isn't fixed" let me remind you about the new definition of that limit: 1. The OSPool is statically allocated at boot time, but can be extended with FOLDR100.PRG (as many times as you like). 2. The OSPool is used for open-file handles, directory (folder) descriptors, and some other stuff (in "big" blocks) and Malloc descriptors (in "little" blocks, 1/4 of a big block). 3. The pool is used efficiently: small blocks are compacted when necessary to optimize big-block availablility. 4. A folder only takes up space in the pool when it is "active." A folder is "active" when it is: a) Some drive's root directory, b) Somebody's current directory, c) The parent of some open files, d) Being traversed during the current OS call, or e) The parent of an "active" folder (recursively). The upshot of this is that if there is room for, say, 40 folders in the pool, you can have up to 40 ACTIVE folders at a time. Just getting a directory listing of a folder only makes it active briefly (during the Fsfirst call, but not during Fsnext's). Then it is not active any more, and the space can be re-used if needed. FOLDR100.PRG when used with the new TOS expands the pool for ALL its clients, not just directory descriptors. I hope this clears up some of the confusion, and I hope you understand why we went this way rather than a "two Malloc's" approach or using a "perfect" malloc (with no restrictions) at the expense of breaking some existing programs. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt