home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18320 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.2 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!news.u.washington.edu!glia!crystal
  2. From: crystal@glia.biostr.washington.edu (Crystal)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Flushing Devices; C= doco (mutter!)
  5. Message-ID: <crystal.726454269@glia>
  6. Date: 8 Jan 93 00:51:09 GMT
  7. Article-I.D.: glia.crystal.726454269
  8. References: <1993Jan7.092127.13752@philips.oz.au> <1iia8tINNdeh@darkstar.UCSC.EDU>
  9. Organization: University of Washington
  10. Lines: 41
  11. NNTP-Posting-Host: glia.biostr.washington.edu
  12.  
  13. In <1iia8tINNdeh@darkstar.UCSC.EDU> davids@cats.ucsc.edu (Dave Schreiber) writes:
  14.  
  15.  
  16. >In article <1993Jan7.092127.13752@philips.oz.au> gduncan@philips.oz.au (Gary Duncan) writes:
  17. >>Passing thought ; why the heck aren't unused libraries/devices
  18. >>flushed automatically anyway? Sounds like a legacy of the days 
  19. >>when hard disks were rare and dragging a device off floppy was
  20. >>time-consuming. Those days are gone...
  21.  
  22. >Why should they be flushed?  An unused library essentially takes up
  23. >zero memory, since the memory it uses can be demanded from it at
  24.  
  25. Then how come running "avail flush" returned 75k of memory to me if they
  26. take up ZERO memory...?
  27.  
  28. >any time (and will be demanded from it before a memory allocation
  29. >is allowed to fail).  The only people for whom auto-removal of
  30. >libraries is important are developers who are checking for memory
  31.  
  32. Warning: you are dealing in absolutes here... developers are not the ONLY
  33. people for whom auto-removal of libraries is important.  Those with
  34. little ram trying to run DTP programs or Database programs that access
  35. large textfiles or graphics likewise need to be able to have as much memory
  36. available to them as possible for their work, too.  
  37.  
  38. >leaks; there are plenty of ways of flushing libraries on those
  39. >rare occassions when it is needed.
  40.  
  41. Ok, so, other than "avail flush", what other ways are there?  I want to
  42. recover as much as I can from those programs that don't clean up after
  43. themselves.
  44.  
  45. >I say this, BTW, as a non-professional developer with lots of hard
  46. >drive space and RAM, and who was checking a program for memory leaks
  47. >two days ago :-).
  48.  
  49. >>Gary Duncan            gduncan@rosella.pts.philips.oz.au    
  50.  
  51.  
  52. >-- 
  53. >Dave Schreiber  "Look.  Don't touch."  davids@cats.ucsc.edu (until 6/20/93)
  54.