home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1394 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  1.6 KB

  1. Path: sparky!uunet!wupost!uwm.edu!rutgers!faatcrl!iecc!compilers-sender
  2. From: tmb@idiap.ch
  3. Newsgroups: comp.compilers
  4. Subject: Re: Adding garbage collection to C++
  5. Keywords: C, GC
  6. Message-ID: <92-08-093@comp.compilers>
  7. Date: 17 Aug 92 16:04:23 GMT
  8. References: <92-08-092@comp.compilers> <92-08-076@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: tmb@idiap.ch
  11. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  12.     Perceptive)
  13. Lines: 22
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. bill@amber.ssd.csd.harris.com (Bill Leonard) writes:
  17.  
  18. >[How do you garbage collect multi-threaded programs where some pointers to
  19. >shared memory are kept in per-thread private storage]
  20.  
  21. >  I think you basically have to give up on garbage collecting such strange
  22. >  objects.  But their existence forces me to advocate that garbage
  23. >  collection only happen if I specifically ask for it (thus begging for
  24. >  language extensions), rather than automatically.
  25.  
  26. You don't need a language extension, nor do you need "garbage
  27. collection only [to] happen if [you] specifically ask for it". Simply
  28. retain a pointer to the object in the address space of A. In fact, you
  29. can encapsulate this behavior nicely inside your "send" procedure.
  30.  
  31.                     Thomas.
  32. [So how do you ever collect storage that's ever been shared between two
  33. threads?  In fairness, this isn't unique to C -- it'd be a problem in any
  34. situation where you have a shared heap with unshared pointers. -John]
  35. -- 
  36. Send compilers articles to compilers@iecc.cambridge.ma.us or
  37. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  38.