home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12773 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  1.3 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!galaxy.dnet!gleeve
  2. From: gleeve@galaxy.dnet
  3. Newsgroups: comp.os.vms
  4. Subject: vms mem mgt
  5. Message-ID: <9207241553.AA23711@relay2.UU.NET>
  6. Date: 24 Jul 92 15:47:04 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 18
  11.  
  12. In the coding of AnalytiCalc I also had to deal with a large but
  13. ordinarily sparse structure. I arranged all accesses to the structure
  14. to be done via calls to a couple routines (a put and a get), then
  15. could modify the routines to access a more limited amount of space
  16. sensibly using files, hash tables, trees, or what have you. If the
  17. person who has to handle his quarter-gig of space can arrange it,
  18. that's a good approach, and it does not need to mess with allocating
  19. lots of tiny parts of process address space.
  20.    It seems conceivable to me that one could insert an exception handler
  21. to catch access violations, then have a routine trap these exceptions
  22. and access a more reasonable structure as I did (and everyone who writes
  23. a spreadsheet does, almost). Just lie to the caller about the address of
  24. the structure so ALL the accesses he tries will trap. Even the overhead
  25. of a condition handler is probably less than that of all the $cretva
  26. calls, and the structure, more sensible.
  27. Glenn
  28. Everhart@Raxco.com
  29.  
  30.