Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cs.yale.edu!fischer-michael From: fischer-michael@CS.YALE.EDU (Michael Fischer) Newsgroups: comp.sys.atari.st Subject: Re: poolfix3 Message-ID: <16819@cs.yale.edu> Date: 23 Feb 90 16:31:00 GMT References: <900218230844.275515@DMZRZU71-UNI-MAINZ--GERMANY> <2047@atari.UUCP> <1990Feb22.195715.1132@ultra.com> Sender: news@cs.yale.edu Reply-To: fischer-michael@CS.YALE.EDU (Michael Fischer) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 56 In article <1990Feb22.195715.1132@ultra.com> jimh@ultra.com (Jim Hurley) writes: >apratt@atari.UUCP (Allan Pratt) writes: > >>Ritzert@DMZRZU71.BITNET writes: > >>>[We have a program which dies; poolfix3 improves it a little.] >>>Question to Allan or Ken: >>> Shall I install folder100 in addition [to poolfix3]? > >>You should certainly use foldr100. Poolfix3 only fixes a bug in >>the code which manages GEMDOS's internal memory. You can still >>run OUT of memory there, and FOLDR100.PRG adds more. A program >>which uses Malloc() a lot, or has lots of open files at the same >>time, can use up all this memory. > >Could you please elaborate? I thought TOS 1.4 fixed the >folder problem. Should one *always* use FOLDRXXX? > >Actually, although I've heard a lot about this bug, I've never >read a consistent description of the problem. Here's my understanding of things: TOS needs memory for various internal things which it takes from a memory pool of FIXED SIZE. When memory is no longer needed, it is returned to the pool for later reuse. FOLDRXXX allows you to increase the size of the pool, and POOLFIX3.PRG fixes a TOS 1.4 bug in the management of that memory. Even with both programs, it is possible to run out of memory, especially if you do a lot of Malloc's, but obviously, the bigger the pool, the less likely you are to run out. TOS 1.0 and 1.2 used the memory less wisely and had varous bugs in the management of the pool that could cause the machine to crash. In particular, it failed to check properly when the pool was exhausted, so when too many folders or too many Malloc's used up the pool, weird things would start happening. The so-called "40-folder" limit was just an empirical observation that users who had at most 40 folders on their disks were unlikely to exhaust memory. Thus, as long as one had at most 40 folders, the problem would not usually be encountered. By increasing the size of the pool, FOLDRXXX allowed more folders to be used. Allan Pratt put a lot of effort into cleaning this up in TOS 1.4. [Thanks, Allan!] You are now much less likely to run out of memory, and crashes shouldn't happen. In particular, inactive folders no longer use memory, so you can have a large number of folders on your disk without needing to increase the size of the pool. However, you still can run out of internal memory and you may well need to use FOLDRXXX to increase the size. If you do run out, the system stops with an "out of internal memory" message and suggests that you increase the size of the pool. ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ==================================================