home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / modula3 / 1086 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.1 KB  |  55 lines
  1. Newsgroups: comp.lang.modula3
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!src.dec.com!East.Sun.COM!Geoff.Wyant
  3. From: Geoff.Wyant@East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
  4. Subject: re:  Forking a threaded Modula 3 process
  5. Message-ID: <9212181327.AA10997@gidney.East.Sun.COM>
  6. Sender: daemon@src.dec.com (System programs)
  7. Organization: DEC Systems Research Center
  8. X-Content-Length: 1632
  9. X-To: m3
  10. Date: Fri, 18 Dec 92 08:27:55 EST
  11. X-Received: by gidney.East.Sun.COM (4.1/SMI-4.1)
  12.     id AA10997; Fri, 18 Dec 92 08:27:55 EST
  13. Lines: 40
  14.  
  15.  
  16. > From: dagenais@vlsi.polymtl.ca (Michel Dagenais)
  17. > Newsgroups: comp.lang.modula3
  18. > Subject: Forking a threaded Modula 3 process
  19. > Date: 17 Dec 92 14:05:49 GMT
  20. > Organization: Ecole Polytechnique de Montreal, Canada
  21. > 
  22. > 
  23. > I want to communicate between a Modula 3 program and another already
  24. > written C program. Ideally, the C program should interact through its
  25. > stdin/stdout/stderr file descriptors. I know how to do that by creating
  26. > pipes, forking the Modula 3 program and exec on the C program. I am worried
  27. > about the multiple threads in the forked process however (they should not
  28. > attemps X windows output and so on). I suppose that adding an interface to
  29. > the "popen" unix call would be cleaner and safer. Advices?
  30. > --
  31. > ---------------------------------------------------------------------
  32. > 
  33. > Prof. Michel Dagenais                dagenais@vlsi.polymtl.ca
  34. > Dept of Electrical and Computer Eng.
  35. > Ecole Polytechnique de Montreal            tel: (514) 340-4029
  36. > 
  37. > ---------------------------------------------------------------------
  38. > 
  39.  
  40. The time between the fork and the exec should be short enough
  41. that threads shouldn't be a problem. After the exec, they will
  42. disappear. On a fast multi-processor, there would be a race condition,
  43. but there isn't much you can do without the requisite kernel support.
  44. Popen would suffer the same race condition as it ultimately does
  45. a fork and an exec as well. If you wanted to be squeaky-clean, you could
  46. have a C-based "exec server" that you sent a message to and it
  47. forked off the program of interest. That would eliminate any M3 threads
  48. from the picture.
  49.  
  50. Hope this helps !
  51.  
  52.  
  53. --geoff
  54.  
  55.