🚀 go-pugleaf

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:    <fischer-michael@cs.yale.edu>   |
|    Bitnet:     <fischer-michael@yalecs.bitnet> |
|    UUCP:       <fischer-michael@yale.UUCP>     |
==================================================