🚀 go-pugleaf

>>>>> On 21 Aug 90 21:43:52 GMT, a218@mindlink.UUCP (Charlie Gibbs) said:
Charlie> Being relatively new to Unix, I'm curious about this.  Is it
Charlie> really that much of a Bad Thing to clean up after yourself, or are
Charlie> we falling into the trap of quibbling over a few milliseconds when
Charlie> our time would be better spent elsewhere?

99.9% of the time, it's best to free() everything you can before starting
another round of malloc()s.  (Duh!-) Explictly free()ing memory before
exit()ing is unecessary under UNIX, _BUT_ today's application often winds
up tomorrow's subroutine.  If you don't at least write the code for
explicit free()ing with #ifdefs around it, you may have to come back a year
or so later and try to figure out how best to patch it in so your new mega
application doesn't leak memory all over the carpet when your (now)
subroutine gets invoked repeatedly.

If rapid (de)allocation of memory is paramount, you shouldn't use malloc()
or free() at all.  The traditional UNIX way is to sbrk() large chunks and
explicitly manage the space yourself.  HOWEVER, System Vr4 has mmap().
(Concieved at Berzerkely, implemented by Sun, I believe.  Thanks, guys!)

Some mmap() Advantages:
	1. You can release mmap()ed memory back to the OS for reuse by
	   other proceses, unlike sbrk() or malloc(), which typically calls
	   sbrk().
	2. You can mmap() a disk file into memory, allowing you to
	   access it just like RAM.
	3. Multiple processes can mmap() the same file into their address
	   space for clean shared memory, compared to shm*() memory IMHO.
	4. mmap()ed memory can be marked "copy on write" so that multiple
	   processes copy only modified parts of an mmap()ed file into
	   their own process space on a page-by-page basis.  (Typical UNIX
	   page sizes run 2-8KB.)
	5. mmap() memory can be explicitly marked for read, write and
	   execute permissions on a process-by-process basis.

There are other reasons, like performance.  These are just off the top of
my head.

	Hope this helps,
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp