home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3793 < prev    next >
Encoding:
Internet Message Format  |  1992-09-04  |  1.5 KB
  1. Xref: sparky comp.unix.wizards:3793 comp.unix.questions:10726
  2. Path: sparky!uunet!pipex!warwick!str-ccsun!strath-cs!baird!jim
  3. From: jim@cs.strath.ac.uk (Jim Reid)
  4. Newsgroups: comp.unix.wizards,comp.unix.questions
  5. Subject: Re: reliable signals under BSD / SVR4
  6. Message-ID: <JIM.92Sep4130431@hunter.cs.strath.ac.uk>
  7. Date: 4 Sep 92 12:04:31 GMT
  8. References: <acourtny.715263267@unix1.tcd.ie> <Btwqvs.LAI@zeus.dialix.oz.au>
  9.     <acourtny.715556934@unix1.tcd.ie>
  10. Sender: news@cs.strath.ac.uk
  11. Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
  12. Lines: 18
  13. Nntp-Posting-Host: hunter
  14. In-reply-to: acourtny@unix1.tcd.ie's message of 3 Sep 92 21:48:54 GMT
  15.  
  16. In article <acourtny.715556934@unix1.tcd.ie> acourtny@unix1.tcd.ie (Antony A. Courtney) writes:
  17.  
  18.    Has anyone investigated other models for signal delivery?  Since signals are
  19.    meant to be analogous to interrupts, wouldn't it be useful to guarantee that
  20.    all signals sent are processed?
  21.  
  22. Not always. For instance, how could a process handle a second KILL or
  23. STOP signal sent to it? Or why would someone want to know how many
  24. times a process has been sent a signal that it was ignoring?
  25.  
  26. In the Good Old Days, signals had one simple function to perform. This
  27. was to inform a process that Something Bad had happened - memory
  28. violation, arithmetic exception, etc - so that the process could do
  29. some cleanup before it terminated. Everything that has been done to
  30. signals since then has added complexity and features that the
  31. mechanism was never originally designed or intended for.
  32.  
  33.         Jim
  34.