gert@nikhefh.hep.nl (Gert Poletiek) (08/23/88)
In article <1125@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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." >[lesson on Malloc deleted] > >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 > [stuff deleted] >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt Allan, To my knowledge there is another reason that a folder can become 'active'. And this is the MOST IMPORTANT reason that the 40 folder limit does exist: Whenever a program performs a Fsfirst and does not 'run to completion' using the Fsnext call you will get the following datastructures: Owned by the program Owned by GemDos DTA structure: 21 bytes OS owned stuff therein: a pointer ---------> active folder data structure (on an odd byte boundary, the orginal TOS author really had a way of coding) rest usable (Read only) by program: attribute, filename time stamp and file length The folder into which the program does its search using Fsfirst becomes active (its being searched, right?). Now in GemDos there is no backward referencing pointer, i.e. a pointer from the active folder structure to an active (not yet completed) DTA search buffer. When the program exits, GemDos has no way of knowing whether the active folder may be removed or not. THIS IS THE REAL REASON FOR THE 40 FOLDER BUG. And the same program may reset (using Fsetdta()) the current process dta address and start creating a whole mess of 'active' folders that can never be cleaned up by TOS. And since there is no equivalent of the UNIX 'stat' call in TOS you are forced to do an Fsfirst to get info on a file. Even if you allocate 1 megabyte for folder structures in TOS memory it still will become depleted!! FOLDRXXX.PRG won't help and FOLDRXXXXXXXX.PRG won't help either. IS THIS FIXED IN THE NEW ROMS???? Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet From september 1st 1988: Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet
apratt@atari.UUCP (Allan Pratt) (08/25/88)
In article <528@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: > [...your DTA contains a pointer to an OS data structure and the OS > can't tell when it's no longer necessary...] > > The folder into which the program does its search using Fsfirst becomes > active (its being searched, right?). Now in GemDos there is no backward > referencing pointer, i.e. a pointer from the active folder structure to an > active (not yet completed) DTA search buffer. > > When the program exits, GemDos has no way of knowing whether the active > folder may be removed or not. THIS IS THE REAL REASON FOR THE 40 FOLDER BUG. I forgot to mention: I reworked Fsfirst/Fsnext so they don't leave a pointer to an OS data structure in your DTA. Therefore Fsfirst or Fsnext in a folder does not make it active (except for the duration of the OS call itself). Sorry, Gert, but this is not the reason for the 40-folder bug. You give the guy who wrote GEMDOS too much credit. He NEVER freed directory descriptors back into the pool. He never even TRIED. There was no provision for this AT ALL. He just ASSUMED that you wouldn't have enough folders to fill up the OSPool. And don't get me started on the interactions between Malloc and folders in the old GEMDOS... ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt