home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4862 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.1 KB  |  87 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!newsfeed.rice.edu!exlogcorp!mcdowell
  3. From: mcdowell@exlog.com (Steve McDowell)
  4. Subject: Re: Changing the owner of a process
  5. Message-ID: <1992Nov23.202603.23026@exlog.com>
  6. Keywords: process ownership
  7. Organization: EXLOG, Inc.
  8. References: <1992Nov17.142837.21252@dale.ksc.nasa.gov> <1992Nov19.220759.1846@exlog.com> <1992Nov23.180757.20627@nuchat.sccsi.com>
  9. Date: Mon, 23 Nov 92 20:26:03 GMT
  10. Lines: 75
  11.  
  12. In message <1992Nov23.180757.20627@nuchat.sccsi.com> steve@nuchat.sccsi.com (Steve Nuchia) writes:
  13. > In article <1992Nov19.220759.1846@exlog.com> mcdowell@exlogcorp.exlog.com (Steve McDowell) writes:
  14. >>Why is it going to panic over an inconsistent process count? That's simply
  15. >>....it should simply alert the operator and re-count things.
  16. >
  17. > Three points:
  18.  
  19. > I'd prefer to have the CSRG's remaining time spent
  20. > on improving fundamental algorithms.
  21.  
  22. Actually, so would I. A big difference here is that I'd like to see the 
  23. state of "fundamental algorithms" expanded to include issues such as fault
  24. tolerance and error recovery. It's too often ignored in practice. 
  25.  
  26. > 2: I may be old-fashioned, but I prefer to have a system panic
  27. > when it detects a "can't happen" bug.  That means something
  28. > has gone wrong.  Under those circumstances, why would you want
  29. > to trust a piece of recovery code that hasn't been tested in
  30. > living memory?
  31.  
  32. First of all, I really don't want a production system with *any* 
  33. code that hasn't been tested "in living memory". Test your code 
  34. before you ship it, the guys over in comp.software-eng will tell
  35. you how...
  36.  
  37. What I've said all along is that I'd like for the kernel to try
  38. and safely resolve the error before panic'ing. Whether that requires 
  39. "voting" by having multiple routines doing recounts in different 
  40. ways and panic'ing if they don't match up, or whether it requires
  41. some other technique from the traditional realtime/fault tolerent
  42. world, I don't know. I think this is definately an area for study.
  43.  
  44. The realtime world has been doing this kind of thing since the 1960's, 
  45. but I keep hearing (in email responses, anyway) that "it can't be
  46. done" or that it "just isn't safe". It can be made safe. It can
  47. be made to work. It just takes an investment of committed resources.
  48.  
  49. > 3: What is the opertator going to do about it, anyway?  If one of
  50. > these counts gets out of whack, somebody who can fix the code needs
  51. > to know about it, fast.  
  52.  
  53. The term "operator" was meant as a generic term indicating the 
  54. person running the computer, whether that person be a developer, field engineer,
  55. or backup clerk.  And usually, somebody who can "fix the code...fast" isn't 
  56. available in the field. I've said before that in the lab, I'm all for doing 
  57. whatever it takes to trace the bugs. 
  58.  
  59. > Something caused the fault, and there is
  60. > literally no telling what else may be broken until the cause is found.
  61.  
  62. Certainly there are some faults that point more towards system corruption
  63. than others -- panic your way out of those. For those that are recoverable, 
  64. and the key word is *recoverable*, then try.  Put in a routine to
  65. recompute a consistant state. Make that routine pass stringent tests to 
  66. give an acceptable degree of certainty before recovering from a 
  67. particular error. If there's uncertainty, then abort. I'm not saying
  68. to run with an inconsistant state, I'm saying to build in the 
  69. intellegence to find a consistant state. 
  70.  
  71. > Of course, if one is building a system for binary-only distribution
  72. > or attempting to provide for non-stop operation, other considerations
  73. > apply.  BSD Unix does not have those design goals.
  74.  
  75. Most systems outside of development labs are binary-only. Most commercial
  76. users would definately appreciate non-stop operation. I think it's the 
  77. responsibility of those building systems to strive towards the goal of
  78. non-stop operation. Error-less code is never going to happen. Error-tolerance
  79. can.
  80.  
  81. Just my humble opinion.
  82. -- 
  83. Steve McDowell             . . . . o o o o o         Opinions are 
  84. Exlog, Inc.                      _____      o         mine, not my 
  85. mcdowell@exlog.com      _____====  ]OO|_n_n__][.        employers..
  86.                [_________]_|__|________)<   
  87.