home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1428 < prev    next >
Encoding:
Text File  |  1992-08-20  |  1.4 KB  |  34 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!decwrl!world!iecc!compilers-sender
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Adding garbage collection to C++
  5. Reply-To: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  6. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  7. Date: Thu, 20 Aug 1992 23:41:50 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-08-128@comp.compilers>
  10. References: <92-08-092@comp.compilers> <92-08-093@comp.compilers>
  11. Keywords: C, GC, parallel
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 19
  14.  
  15. >[How do you garbage collect multi-threaded programs where some pointers to
  16. >shared memory are kept in per-thread private storage]
  17.  
  18.     Clearly you have to GC at the level of sharing. If A and B share
  19. storage, you have to make the collector scan the stacks of both A and B.
  20. So the collector needs to be implemented in the Operating system.
  21.  
  22.     Perhaps simply retaining a pointer in the address space of A works
  23. for threads, but it doesnt work for systems like Windows, where you 'give
  24. away' the pointer to the OS. There IS no stack or local address space
  25. between callbacks into you're program, so there is nowhere to retain that
  26. pointer.
  27.  
  28. -- 
  29.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  30.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  31. -- 
  32. Send compilers articles to compilers@iecc.cambridge.ma.us or
  33. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  34.