home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / softsys / andrew / 1393 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.4 KB  |  98 lines
  1. Newsgroups: comp.soft-sys.andrew
  2. Path: sparky!uunet!haven.umd.edu!purdue!decwrl!adobe!usenet
  3. From: zstern@adobe.com (Zalman Stern)
  4. Subject: Re: communication between Adew controllers
  5. Message-ID: <1992Nov23.220317.17837@adobe.com>
  6. Sender: usenet@adobe.com (USENET NEWS)
  7. Organization: Adobe Systems Incorporated
  8. References: <1992Nov20.205516.1211@csi.uottawa.ca>
  9. Date: Mon, 23 Nov 1992 22:03:17 GMT
  10. Lines: 86
  11.  
  12. In article <1992Nov20.205516.1211@csi.uottawa.ca>  
  13. isabelle@shamin.genie.uottawa.ca (Isabelle Tourneux) writes:
  14. > 
  15. > First, thank you very much for all the detailed answers you have
  16. > given me concerning message queues. This has however led me to
  17. > other questions :
  18. > 
  19. > I have several adew "view+controller" in the same machine, which
  20. > are spawned successively with forks and execs. I would like to have
  21. > them communicate with each other. So I have looked at all the
  22. > possible means of communication between these controllers. I am
  23. > using System V.
  24.  
  25. Which System V?
  26.  
  27. > - interruptions would be a nice solution, but I have not managed
  28. > to get the pid of the controller without clicking somewhere on the
  29. > view. A getpid() in controller_go gives the pid of runadew I guess.
  30. > Moreover, runadew puts the group id of the controller equal to the
  31. > pid of this controller, so I cannot get the group id of the
  32. > controller without clicking on the view, as for the pid. Is it
  33. > possible to change the code of runadew to prevent it from
  34. > initializing the group id of the controller ? Do you think
  35. > interruptions would work as I am working under System V and Xwindows
  36. > ?
  37. I assume you mean "signals" when you say "interruptions." Depending on the  
  38. version of System V you are using (i.e. you want reliable signals) it might  
  39. be possible to get this to work. My personal philosophy is that signals are  
  40. best used for exceptional conditions and should be avoided for other things.  
  41. Mostly due to the difficulty of debugging asynchronous code, but also due to  
  42. really bad experiences with kernel bugs involving signals.
  43.  
  44. > 
  45. > - I know sockets would be a solution, but I would prefer not to
  46. > use them for internal communication between processes runing on
  47. > the same machine : I am afraid I will not be able to send a huge
  48. > file through a socket without cutting it into smaller parts, and I
  49. > would like to avoid that. Do you think Unix Domain Sockets could
  50. > allow me to send huge file without cutting them ?
  51.  
  52. I have no idea why you claim this is a problem. Both UNIX domain and TCP  
  53. sockets should work fine for this application. This would be my personal  
  54. favorite.
  55.  
  56. > - as all my controllers have got different names, I have thought
  57. > about memorizing the pointers on each controller in a memory shared
  58. > by all the processes :
  59. >  struct controlleri * ptri ( i = 1, 2...),
  60. > and call functions of a controller from another controller, using
  61. > this pointers : controller1_thisFunction(ptr1) in the code of the
  62. > 2nd controller for instance.
  63. > The 1st controller is running, but the function is not called
  64. > successfully, and there is a segmentation fault. Before, I had
  65. > never had problems with memorizing pointers on an ATK view or
  66. > dataobject in another ATK view or dataobject, and calling
  67. > functions with these pointers. Is there something specific to adew
  68. > which prevents from doing that ? 
  69. > 
  70.  
  71. I don't know enough about ADEW to understand this question.
  72.  
  73. >                          I am trying at any rate to establish a
  74. > communication between Adew controllers, but it is hard because adew
  75. > and runadew were not written for that kind of application, but were
  76. > supposed to be used only for prototyping. Anyway I really want to
  77. > find a way of establishing these connections, even if the solution 
  78. > is not the most elegant.
  79.  
  80. I guess my high level answer would be that you want an RPC package to ease  
  81. communication between separate processes. If nothing else some sort of name  
  82. service seems in order. Of course that may be too much work. The simple  
  83. method is to drop a bunch of port numbers into a file all the processes can  
  84. access and use sockets for communication. Be sure to use proper locking  
  85. discipline on the file.
  86.  
  87. > 
  88. > Thanks for your help.
  89. > 
  90. > isabelle Tourneux
  91. > Multimadia Lab of the University of Ottawa.
  92. > isabelle@shamin.genie.uottawa.ca
  93.  
  94. --
  95. Zalman Stern           zalman@adobe.com            (415) 962 3824
  96. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  97.   "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
  98.