Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wes
From: wes@obie.UUCP (Barnacle Wes)
Newsgroups: comp.sys.atari.st
Subject: Re: fsel_input
Message-ID: <82@obie.UUCP>
Date: 22 Mar 88 16:43:10 GMT
References: <8802250623.AA17637@ucbvax.Berkeley.EDU> <194@actisb.UUCP>
Organization: the Well of Souls
Lines: 29
Summary: Malloc bugs & more

In article <194@actisb.UUCP>, federico@actisb.UUCP (Federico Heinz) writes:
> There again, I've repeatedly read in the net that Malloc is buggy, and that
> a certain amount of Malloc/Mfree calls per process fully messes up the
> system.

Yah, that's a little bit of brain damage GEMDOS inherited from
MeSS-DOS: the Malloc/Mfree system uses "memory handles" to store
information on the Malloc'd blocks, and there seem to be about 20
handles per process (makes sense, that's how many file handles there
are).  There were ways of getting around this in MS-DOS, but GEMDOS
does not seem to use exactly the same scheme, and the work-arounds
don't work.

The usual way to get around this is to write your own malloc/free
routines.  The start-up file checks to see how much memory is
available (use Malloc(-1L)) and divides it into 20 chunks.  When you
call malloc, it looks to see how much is available, if not enough, it
calls Malloc to get another 1/20th of available memory, and allocates
it out of that.

If you use MWC, this is already done for you.  Of course, that makes
your fsel_input MWC specific.  You win a few, you loose a dozen.

	Wes
-- 
    /\              -  "Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!utah-gr!
  /    \/ \/\/  \   -   Contend in Vain."   -  uplherc!sp7040!
 / U i n T e c h \  -       Schiller        -     obie!wes