home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4584 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.1 KB
  1. Path: sparky!uunet!vtserf!vttcf.cc.vt.edu!valdis
  2. From: valdis@vttcf.cc.vt.edu (Valdis Kletnieks)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: Process 'purge' revisited.. Unix missing this?
  5. Message-ID: <9348@vtserf.cc.vt.edu>
  6. Date: 10 Nov 92 09:52:55 GMT
  7. References: <TPAQUETTE.92Nov6132758@gumby.ita.lgc.com>
  8. Sender: usenet@vtserf.cc.vt.edu
  9. Organization: Virginia Tech, Blacksburg, VA
  10. Lines: 42
  11.  
  12. In article <TPAQUETTE.92Nov6132758@gumby.ita.lgc.com> tpaquette@ita.lgc.com (Trevor Paquette) writes:
  13. > All the responses I have recieved have all said exactly what I thought.
  14. >It is impossible to 'purge' a process witing on a hung device.
  15. >
  16. > Is this a deficency in Unix? Should it be added? Will I ever win the
  17. >lottery?
  18.  
  19. No, it's a deficiency in operating systems in general.
  20.  
  21. Now let's look at what happens:
  22.  
  23. You have a "process"/"task"/whatever you want to call it that initiates
  24. an I/O transfer to a device.  Said device mysteriously flames out
  25. before the transfer completes.  You're sitting there with a process
  26. that has some buffers locked in memory as a target for the I/O.
  27.  
  28. What should you do?
  29.  
  30. You can't just kill the process and free the buffers - that device might
  31. wake up and complete the I/O over where the buffers USED to be.
  32. Unless you're willing to bet the system that you have managed to FOR SURE
  33. abort an in-progress transfer, you have to keep enough state around
  34. so that if it DOES complete, you won't get torched.
  35.  
  36. SImply pretending the I/O is gone loses too - the process may get
  37. confused, and if the I/O *does* complete, you're torched.
  38.  
  39. Killing the process and not freeing the buffers gets interesting, as
  40. you have to then find some way of dealing with the buffers - most
  41. operating systems kind of make an assumption that allocated real
  42. memory *belongs* to somebody - so a "kill the process and free all but
  43. these 960 bytes" gets interesting.  
  44.  
  45. And of course all sorts of OTHER warts arise in the real world.. ;)
  46.  
  47. Feel free to propose what you think it should do - and remember in
  48. your design to address all the failure modes (Heck, we only *get*
  49. into this situation if something has failed already)....
  50.  
  51.                 Valdis Kletnieks
  52.                 Computer Systems Engineer
  53.                 Virginia Tech
  54.