home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3765 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.3 KB
  1. Xref: sparky comp.unix.wizards:3765 comp.unix.questions:10629
  2. Newsgroups: comp.unix.wizards,comp.unix.questions
  3. Path: sparky!uunet!munnari.oz.au!uniwa!DIALix!zeus!peter
  4. From: peter@zeus.dialix.oz.au (Peter Wemm)
  5. Subject: Re: reliable signals under BSD / SVR4
  6. Message-ID: <Btwqvs.LAI@zeus.dialix.oz.au>
  7. Keywords: signals, reliable, software interrupts
  8. Organization: Karam Pty. Ltd. Perth, Australia
  9. References: <acourtny.715263267@unix1.tcd.ie>
  10. Date: Tue, 1 Sep 1992 16:23:52 GMT
  11. Lines: 58
  12.  
  13. acourtny@unix1.tcd.ie (Antony A. Courtney) writes:
  14.  
  15. >I wrote the following short program to test whether or not signals are reliable
  16. >on our particular SVR4 implementation  (A Siemens-Nixdorf RM600 running Sinix).
  17.  
  18. >The particular implementation of signal() is from Stevens' "Advanced Programming
  19. >in the UNIX environment".  
  20.  
  21. >The program simply installs a signal handler for SIGUSR1, fork()s, and the
  22. >parent sends 20 SIGUSR1 signals to the child as fast as it can.  The child
  23. >has a busy loop in the signal handler to make it deliberately slow.  The result
  24. >is that I only catch a random subset of the signals posted (sometimes I don't
  25. >catch any, other times I get 2 or 3).  I get similar behavior under 4.3BSD if
  26. >I use BSD's implementation of signal(), which is supposedly "reliable".
  27.  
  28. >What's the word?  Are signals "reliable" or aren't they?
  29.  
  30. >I admit I haven't read *every* single standard written about all the various
  31. >implementations and semantics of signals; that would probably take more time
  32. >than writing a reliable signal implementation!
  33.  
  34. >Code follows, thanks for any help...
  35.  
  36. >    -antony
  37.  
  38. >--
  39. >******************************************************************************
  40. >* Antony A. Courtney                            Email: acourtny@unix1.tcd.ie *
  41. >* Computer Science Department                          antony@george.lbl.gov *
  42. >* Trinity College, Dublin, Ireland              Phone: 01+353+1-607389       *
  43.  
  44. [code deleted for brevity]
  45.  
  46. Isn't the point of reliable signals to make sure that the handler is
  47. always valid, and there are no "danger" windows while the signal
  48. handler is set to SIG_DFL?
  49.  
  50. In "old" unix, when a signal was posted, the handler was called, and the
  51. signal handler vector was reset to SIG_DFL. If another signal followed
  52. afterwards, it could potentially kill the process.  The handler could
  53. re-arm the signal vector to point back to itself, but there is a danger
  54. window between the start of the handler and the re-arming.
  55.  
  56. BSD/POSIX/SVR4 signals to not automatically "reset" to default on
  57. actication, and the signal is usually *masked* to prevent a recurring
  58. signal from within the handler.  The mask is cleared when the handler 
  59. returns.  I dont seem to remember anything about reliable stacking or 
  60. queueing of signals in this model.  I think this is implemented
  61. in the kernel as a bitmask, so at theoretically one of each signal could
  62. be queued up. I'm not sure about other implementations (other than 
  63. SVR4/386, that is...).
  64.  
  65. Sigaction can be set to do many wonderful things though...
  66. -- 
  67. Peter Wemm : peter@zeus.dialix.oz.au     If it's broke, fix it (The MS-DOS way)
  68. Work phone: +61-9-479-1855      If it aint broke, don't touch it (The Unix way)
  69. Fax: +61-9-479-1134     If we can't fix it, it ain't broke (Maintainer's Motto)
  70.   "Don't give me that intelligent life cr*p, find me something to blow up!"
  71.