Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ll-xn!mit-eddie!bbn!gatech!emcard!mat
From: mat@emcard.UUCP (Mat Waites)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Disk corrupt - task held
Keywords: guru to the maximum frustrastion
Message-ID: <5677@emcard.UUCP>
Date: 16 Jun 88 17:39:06 GMT
References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP> <2108@sugar.UUCP> <5564@xanth.cs.odu.edu> <2120@sugar.UUCP> <5597@xanth.cs.odu.edu>
Reply-To: mat@emcard.UUCP (Mat Waites)
Distribution: na
Organization: Emory University Cardiac Data Bank
Lines: 29

In article <5597@xanth.cs.odu.edu> kent@cs.odu.edu (Kent Paul Dolan) writes:
>
>	Does "Unix jobs never shrink" mean "free" is a scam?  This really
>	doesn't affect the argument, though, ....
> ...
>Kent, the man from xanth.


The malloc() / free() implementations I've worked with never shrink.
malloc() calls a lower level memory allocation routine to allocate chunks
of memory. These chunks are often much larger than what was requested,
but malloc returns you a pointer to a piece the size you asked for.
On your next malloc call, there could possibly be enough memory still around
from the first chunk to immediately return your malloc'ed bit of memory.

When you free(), the malloc'ed memory is returned to a LOCAL pool of memory
available for future malloc'ing. It doesn't return to the system until your
process exits.

(hey, Unix was just written by a couple of guys foolin' around. What can
you expect?)

Mat


-- 
  W Mat Waites                     |  PHONE:  (404) 727-7197
  Emory Univ Cardiac Data Bank     |  UUCP:   ...!gatech!emcard!mat
  Atlanta, GA 30322                |