home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 4997 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  2.7 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object
  4. Subject: Re: Rethinking the Object Paradigm
  5. Message-ID: <PCG.93Jan22154531@decb.aber.ac.uk>
  6. Date: 22 Jan 93 15:45:31 GMT
  7. References: <C0wHIw.GM8@clear.com>
  8. Sender: news@aber.ac.uk (USENET news service)
  9. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  10. Organization: Prifysgol Cymru, Aberystwyth
  11. Lines: 45
  12. In-Reply-To: rapp@clear.com's message of 15 Jan 93 14: 56:55 GMT
  13. Nntp-Posting-Host: decb.aber.ac.uk
  14.  
  15. >>> On 15 Jan 93 14:56:55 GMT, rapp@clear.com (Chuck Rapp) said:
  16.  
  17. Rapp> If all objects exist within a single process, an operation may be
  18. Rapp> accessed via a routine call, i.e. pushing the arguments for the
  19. Rapp> operation on a stack frame and jumping to the start of the
  20. Rapp> operation's code. That is how C++ (my lingua franca) interprets a
  21. Rapp> reference to an object's operation.
  22.  
  23. Rapp> But what if the objects are spread across multiple processes and
  24. Rapp> multiple computers? Obviously the above technique simply won't
  25. Rapp> work because there is no way for one process to access another
  26. Rapp> process' stack or code.
  27.  
  28. Not so obvious... If one is clever this *is* possible. My long term
  29. project (started ten years ago, and constantly sidetracked, but might be
  30. finished in a year or so) is an OS kernel in which this is possible. The
  31. technique is very easy: to make a thread jump from one machine to
  32. another, just copy the (last relevant part of the) stack segment to the
  33. machine where the operation's code resides (of course if the two address
  34. spaces are on the same machine one just remaps the stack segment).
  35.  
  36. Rapp> The solution is for some sort of message passing between objects.
  37.  
  38. Not at all; one just makes threads jump from one address space to
  39. another, as decribed above. Each address spaces contains one or more
  40. "type managers" (a.k.a. classes, more or less).
  41.  
  42. Thread passing has also been "reinvented " by other people; for example
  43. the Rochester people that did Elmwood and Psyche and the GeorgiaTech
  44. people that did Clouds (even if they speak of making threads jump from
  45. object to boejct, not class to class, which is rather odd; an
  46. interesting set of papers is available by anonymous FTP from
  47. "helios.cc.gatech.edu"); on a much more sophisticated scale it was the
  48. central idea of Flex by the people at the Malvern RSRE.
  49.  
  50. If you want to get really farther back, the technology (albeit for the
  51. non distributed case, but already in essence there) was first introduced
  52. in the PDP-1.
  53.  
  54. My usual observation that most OO people, and not just Hathaway, are
  55. unaware of things like capability architectures applies. Too bad for
  56. them.
  57. --
  58. Piercarlo Grandi <pcg@aber.ac.uk> c/o Dept of CS
  59. University of Wales, Penglais, Aberystwyth SY23 3BZ, UK
  60.