home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / programm / 4364 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.3 KB
  1. Path: sparky!uunet!caen!nic.umass.edu!dime!patrick
  2. From: patrick@themis.cs.umass.edu (Patrick Healy)
  3. Newsgroups: comp.unix.programmer
  4. Subject: handling SIGCHLD correctly and reusing broadcast sockets
  5. Message-ID: <52042@dime.cs.umass.edu>
  6. Date: 19 Aug 92 00:06:22 GMT
  7. Sender: news@dime.cs.umass.edu
  8. Reply-To: patrick@themis.cs.umass.edu (Patrick Healy)
  9. Organization: University of Massachusetts, Amherst
  10. Lines: 49
  11.  
  12.  
  13.  
  14. M/C: DECstation 5000; OS: Ultrix 4.2c
  15.  
  16.  
  17. Two questions:
  18.  
  19. (1)  How do I correctly handle SIGCHLD signals from exiting children?
  20. (2)  Can I use the same UDP port to both receive a broadcast and respond to
  21. the broadcast?
  22.  
  23. Elabortions:
  24.  
  25. (1) In a server I'm building, I would like to know when a forked off process
  26. completes so that I can check its exit status and wait() on it.  So I handle
  27. the SIGCHLD by wait3() and check the status of each of my processes, onyl
  28. paying attention to the processes that have exited since I last called
  29. wait3().
  30.  
  31. My problem with this scheme is that program may be in the middle of a system
  32. call to what Stevens calls a "slow device."  The system call (e.g, accept()) is
  33. interrupted and I now have to deal restarting the system call etc.  Can people
  34. tell me if there is a more elegant way of allowing me to handle the SIGCHLD
  35. without having to go back and modify my every accept, read and write to that it
  36. handles the interrupt in the correct way.  Right now, rather than deal with
  37. that I have just decided to wait until a new request comes in before I wait3()
  38. on the old one.  Thus, I always have one <exiting> process lying around.
  39.  
  40.  
  41. (2)  How can I use *one* datagram socket to broadcast a message and receive a
  42. response on the same socket?
  43.  
  44. When my client starts up, it won't know where the server currently resides.
  45. So the first thing it does is sends out a broadcast asking that the server
  46. make itelf known to it.  I would now like the server to reply (and send a
  47. small amount of other configuration information) using the *same* socket.  Can
  48. this be done?  It would seem to require setting/resetting SO_BROADCAST on the
  49. socket, but anything more than that I can't figure out.
  50.  
  51.  
  52.  
  53. Answers or comments to either of these questions would be greatly appreciated.
  54.  
  55. Thanks,
  56. Paddy Healy.
  57.  
  58. ===============================================================================
  59. Patrick Healy:    patrick@themis.cs.umass.edu
  60. Guest of:    CS Department
  61.