🚀 go-pugleaf

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