rob@raksha.eng.ohio-state.edu (Rob Carriere) (08/29/88)
Some people had a discussion on Malloc/Fsfirst(next)/40folders from which I inferred that after doing Fsfirst you should always Fsfnext until failure, or you will leave a permanently allocated buffer in your wake. Is this correct? If not, what is the truth? Are there other allocation fee-churs like this? Second question: is there a way to get docs on the lineA functions, other than becoming a registered developer (that'd be a joke!)? If so, how. If not, why not? Thanks, Rob Carriere
apratt@atari.UUCP (Allan Pratt) (08/30/88)
In article <539@accelerator.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu (Rob Carriere) writes: > > Some people had a discussion on Malloc/Fsfirst(next)/40folders from > which I inferred that after doing Fsfirst you should always Fsfnext > until failure, or you will leave a permanently allocated buffer in > your wake. Is this correct? If not, what is the truth? Are there > other allocation fee-churs like this? You haven't been paying attention, but that may be symptomatic of other people so I'll reply (again) here. Fsfirst/Fsnext has NEVER been the culprit in the 40-folder bug. GEMDOS has NEVER had a concept of folders which are "in use" versus folders which are not. It allocated internal memory for a folder as soon as it came across it: getting a directory listing of a directory with subdirectories caused memory to be allocated for those subdirectories. This memory was NEVER released or reused. The new GEMDOS (in the impending TOS 1.4 release) *does* have a notion of "active" folders, as I have described here before. I totally reworked Fsfirst/Fsnext so they do NOT contribute to the definition of an "active" folder, and therefore you do not need to exhaust an Fsfirst in order to relase any resources it has locked -- there are no such resources. Go back and read my previous postings for more details. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
saj@chinet.UUCP (Stephen Jacobs) (08/30/88)
Rob Carriere asked about getting Line A documentation without becoming a registered developer. It isn't free, but the linea.h file from Mark Williams C has about the best line A documentation I've run across. A little concise, but understandable. The compiler is ok too.
rob@kaa.eng.ohio-state.edu (Rob Carriere) (08/31/88)
In article <6429@chinet.UUCP> saj@chinet.UUCP (Stephen Jacobs) writes: > >Rob Carriere asked about getting Line A documentation without becoming a >registered developer. It isn't free, but the linea.h file from Mark Williams Well, it is, since I have the compiler... >C has about the best line A documentation I've run across. A little concise, >but understandable. The compiler is ok too. ^^^^^^^^^^^^^^^^ Candidate for the understatement of the year? ^^^^^^^^^^^^^^^^^^^^^^^ Amen. I had seen the file, and I'm sure I can experiment my way into understanding from there, but I was wondering if there was actually something worthy of name ``documentation'' around (as opposed to ``pretty good hints''). Many thanks anyway. Rob Carriere
dlm@druhi.ATT.COM (Dan Moore) (09/01/88)
in article <1143@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: > > Fsfirst/Fsnext has NEVER been the culprit in the 40-folder bug. GEMDOS > has NEVER had a concept of folders which are "in use" versus folders > which are not. It allocated internal memory for a folder as soon as it > came across it: getting a directory listing of a directory with > subdirectories caused memory to be allocated for those subdirectories. > This memory was NEVER released or reused. > > ... > > ============================================ > Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. > reflect those of Atari Corp. or anyone else. ...ames!atari!apratt Fsfirst/Fsnext have always been a big problem with the 40 folder limit. Since the DTA contains a pointer to a directory node, a node is "used" while in a Fsfirst/Fsnext loop. Those programs that didn't call Fsnext till a failure caused a LOT of nodes to be lost (even more than "normal"). Some early versions of GDOS had this problem, they could cause 20 to 300-400 nodes to be used while the ST was booting (the numbers varied based on the files/folders on the boot drive). Apparently they did a Fsfirst to get file size information which tied up a directory node entry forever. Dan Moore AT&T Bell Labs Denver dlm@druhi.ATT.COM