MEGGIN@vm.epas.utoronto.ca (David Megginson) (12/11/89)
In both TOS 1.2 and TOS 1.4, I have noticed that if a program allocates
_all_ of RAM to itself, the ST will die on disk i/o with a system
shutdown message. Perhaps this is the problem that Diane Barlow Close
has mentioned.
David Megginson, Centre for Medieval Studies, Torontoapratt@atari.UUCP (Allan Pratt) (12/12/89)
Mr. John Sudikatus, quoted by Diane Barlow Close, suggests that the 40-folder limit has returned with a vengeance in TOS 1.4. He is wrong. He says that the space where memory block descriptors are maintained and the space where directory node descriptors are maintained overlap. This is true. But this is no bug: both data structures, and some other things, are dynamically allocated out of the same pool of memory (called "the OS pool"). He says that using FOLDRXXX.PRG will alleviate the problem. He is right, but not for the reason he thinks. The root of all this evil is that the OS pool itself is statically allocated. There is only so much room there, for directory descriptors, memory block descriptors, and open-file descriptors. Using FOLDRXXX.PRG adds more memory to be used for these things. The original problem with the pool was that it was not only statically allocated, but it was also managed poorly: once a piece of the pool was used as (say) a memory descriptor, it was forever tagged as a memory descriptor, and could never be used as a directory descriptor. Starting with TOS 1.4, this is no longer the case. When something allocated from pool is freed, the memory becomes available for any other data structure which is allocated from the pool. Furthermore, once a directory descriptor was allocated from the pool, IT WAS NEVER FREED. It stood forever, recording its place in the directory structure, even if you never used that directory again. And it was allocated if you even so much as SAW the name of the directory in a window, let alone actually opened that directory. I fixed that, too, so only "active" directories take up memory in the pool, and others can be freed when the memory is required for something else. That's why I say that TOS 1.4 pushes the limits of the admittedly-evil static OS pool farther away than previous OSes. And using FOLDRXXX.PRG adds pool (for all its uses, not just folders), so you can push the limits arbitrarily far. Finally, CACHEXXX.PRG has nothing to do with any of this. CACHEXXX.PRG adds sectors to the sector cache which GEMDOS uses, and therefore saves disk accesses. The cache is managed with a "global least-recently used" algorithm, which means that the last N sectors you used are in the cache. You can see this most dramatically if you use "Show Info" from the desktop on a hard disk drive with lots of subdirectories and files. "Show Info" goes down the entire directory tree and reads each sector of the FAT. Do it once, and the disk light will stay on for a while. Do it again, and the same thing happens. Now run CACHE080.PRG and try "Show Info" twice: the first time, the same thing happens. The second time, the disk light doesn't come on at all, because all the sectors are already cached. This speedup is even more dramatic with floppies! Sectors are eligable for this cache when they are read by GEMDOS itself (like directory and FAT sectors) or when they are not read in whole-sector blocks. Disk reads which span entire sectors are transferred directly from disk to their destination in user memory. Please feel free to pass this message along, especially to the place where Mr. Sudikatus' message appeared. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt