home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16460 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.5 KB  |  61 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!utcsri!newsflash.concordia.ca!garrot.DMI.USherb.CA!uxa.ecn.bgu.edu!mp.cs.niu.edu!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!destroyer!gumby!yale!yale.edu!ira.uka.de!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!news.netmbx.de!Germany.EU.net!mcsun!sunic!seunet!enea!ermes!eny
  3. From: eny@ermes.enea.se (Erik Nykvist)
  4. Subject: Re: C++ and Shared Memory (Was: Linked Lists in Shared Memory: )
  5. Message-ID: <1992Nov16.193935.10319@ermes.enea.se>
  6. Organization: Project ERMES, Teli Telecom Sweden
  7. References: <1992Nov11.202728.7564@lsil.com>
  8. Date: Mon, 16 Nov 1992 19:39:35 GMT
  9. Lines: 50
  10.  
  11. ameesh@lsil.com (Ameesh Desai) writes:
  12. > In article 22735@ermes.enea.se, eny@ermes.enea.se (Erik Nykvist) writes:
  13. > >> >=========
  14. > 
  15. > [stuff deleted]
  16. > 
  17. > >The proposed technique uses the new-operator  with placement-syntax to
  18. > >fix the vtbl-pointer in the object. 
  19. > >I have not thought about this very much. I have written ONE example
  20. > >program that uses this. 
  21. > >My idea is that if you know the address of the object in shared memory
  22. > >you could access it after having fixed the vtbl-pointer.
  23. > >If you fork your process it is NOT necessary to fix the vtbl-pointer
  24. > >because the forked process has the vtbl at the same address as the
  25. > >parent process.
  26. > >
  27. > >Erik Nyquist
  28. > >
  29. > 
  30. > 
  31. > I guess if all processes that were to access the shared mem were to have the
  32. > same parent (forked from one single process), what you say is true. However,
  33. > in a more general case, you would like to provide access to the shared 
  34. > memory to processes that do not share the same parent.
  35. > 
  36. > It is not clear to me if there is a "clean" way to share the pages simultaneously
  37. > accross such processes. (when the pages contain C++ objects with vtbl ptrs).
  38. > 
  39. > Ameesh
  40. > 
  41. My idea was to change the value of the vtbl-pointer each time a
  42. context switch occurs. 
  43. There are many disadvantages with this approach. 
  44. One is that only one process may call virtual functions for the object at
  45. the same time. Another one is that it is difficult to design a
  46. constructor that doesn't change the object.
  47.  
  48. The opposite approach seen in some articles is to make certain that the 
  49. vtbl-address doesn't have to change when a contex switch occurs. This
  50. method requires that the executables are linked in a way that
  51. guarantees that the same address is used for the vtbl in both
  52. processes. 
  53. The only problem with this approach is that it is linker-dependent. 
  54.  
  55. Well, ...
  56.  
  57. Erik Nyquist email: erny@enea.se
  58.  
  59.  
  60.  
  61.