home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18379 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.3 KB

  1. Path: sparky!uunet!cbmvax!bj
  2. From: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Flushing Devices; C= doco (mutter!)
  5. Message-ID: <38423@cbmvax.commodore.com>
  6. Date: 8 Jan 93 19:01:10 GMT
  7. References: <1993Jan7.092127.13752@philips.oz.au> <1iia8tINNdeh@darkstar.UCSC.EDU> <crystal.726454269@glia>
  8. Reply-To: bj@cbmvax.commodore.com (Brian Jackson - Amiga Networking)
  9. Organization: Commodore, West Chester, PA
  10. Lines: 55
  11.  
  12. In article <crystal.726454269@glia> crystal@glia.biostr.washington.edu (Crystal) writes:
  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. You have a fundamantal misunderstanding of how this all works.  Libraries,
  46. devices, fonts, etc all stay in memory after use so that if someone needs
  47. them later on they are already in place and don't need to be reloaded again
  48. and again. But all of these things have internal user counts that are zero
  49. if no one has them open at the time.  That means that the system can 'know'
  50. what things can be deleted from memory if another program needs the ram
  51. space.  So, if you run up an application that needs a bunch of memory
  52. (more than is currently available as shown by 'avail') the system will try
  53. to flush everything with a zero user count.  Anything that gets flushed by
  54. doing an 'avail flush' will be flushed by the system under these conditions. 
  55.  
  56. As for wanting to "recover as much as I can from those programs that don't 
  57. clean up after themselves" the fact is that the system can do nothing
  58. about application resources that are not returned by the applications.
  59. An 'avail flush' simply forces the system to do what it would do _anyway_
  60. once you ran up your DTP program.
  61.  
  62.        +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
  63.        Brian Jackson    Amiga Networking Group, Commodore-Amiga Inc.
  64.                         bj@cbmvax.commodore.com
  65.      {uunet|rutgers}!cbmvax!bj    or   networking@cbmvax.commodore.com
  66.                        uva uvam vivendo varia fit 
  67.