home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / aix / 13664 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.7 KB  |  53 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!greenber.austin.ibm.com!jfh
  3. From: jfh@greenber.austin.ibm.com (John F Haugh II)
  4. Subject: Re: * IDLE OUT ON RS/6000 *
  5. Sender: news@austin.ibm.com (News id)
  6. Message-ID: <C1A3CG.2I0J@austin.ibm.com>
  7. Date: Fri, 22 Jan 1993 23:17:04 GMT
  8. References: <727306479@romeo.cs.duke.edu> <C14Dzu.owr@austin.ibm.com> <1993Jan20.104701.4825@pollux.lu.se>
  9. Organization: AIX Software Support, Austin, Republica de Tejas
  10. Lines: 41
  11.  
  12. In article <1993Jan20.104701.4825@pollux.lu.se> gs@balder.tf1.lu.se (Goran Svensson) writes:
  13. >This has been a loooong story. Months ago I filed an complaint (to IBM)
  14. >about processes not dying when an telnet connection was broken and my
  15. >point was that SIGHUP should be delivered when the terminal was disconnected.
  16. >
  17. >The answer was that waiting for SIGHUP was wrong. What I should do was
  18. >to look for the status code on a IOrequest to my terminal and if that was an
  19. >EOF, then I should go climb a nearby tree. I do not like this scheme, mostly
  20. >because if I have a CPU bound program it will go on forever.
  21. >
  22. >It has something to do with POSIX be unclear or whatever ...
  23. >What is your reaction? I feel that a SIGHUP should be delivered, but I am
  24. >not in the position to argue with N.N. (name withhold) is Austin Tejas
  25.  
  26. This is what POSIX says.
  27.  
  28. 3.2.2.3
  29.     (4) Termination of a process does not directly terminate its chilren.
  30.     The sending of a SIGHUP signal as described below indirectly
  31.     terminates children in some circumstances.
  32.     (6) If the process is a controlling process, the SIGHUP signal
  33.     shall be sent to each process in the foreground process group of
  34.     the controlling terminal belonging to the calling process.
  35.     (8) If the implementation supports job control, and if the exit of
  36.     the process causes a process group to become orphaned, and if any
  37.     member of the newly-orphaned process group is stopped, then a SIGHUP
  38.     signal, followed by a SIGCONT signal shall be sent to each process
  39.     in the newly-orphaned process group.
  40.  
  41. OK.  If the process which was not dying was a back-ground process, you are
  42. out of luck unless the backgrounded process was asleep.  If the process was
  43. in the foreground process group, and it wasn't being sent SIGHUP, then you
  44. have a defect and should call it in.
  45.  
  46. I did write a quick little testcase, and we do the right thing.  If you 
  47. are the foreground process, and your process leader dies, you get a SIGHUP.
  48. If you are in the background and not stopped, you get no signal.
  49. -- 
  50. John F. Haugh II      | Quality is ... knowing who |  MaBellNet: (512) 823-8817
  51. SneakerNet: 042/2F068 | your customer is and what  |      VNET: HAUGH at AUSVM8
  52. [ DoF #17 ] [ TSAKC ] | your customer wants.       |  Disc: I speak 4 me, !IBM.  
  53.