Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (08/30/90)
>>>>> 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?
Explictly free()ing memory before exit()ing is unecessary under UNIX, but
(as has been pointed out) 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 for _fast_ (de)allocation 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 (while maintaining memory protection).
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 for using mmap(), 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