home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0083.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.0 KB
  1. From: seismo!munnari!yabbie.rmit.oz!rcodi@sally.utexas.edu (Ian Donaldson)
  2. Date: Tue, 21 Oct 86 10:39:40 EST
  3.  
  4. > From: im4u!caip!hplabs!hpda!hpisoa1!davel@sally.utexas.edu (Dave Lennert)
  5. > Date: Thu, 9 Oct 86 14:06:30 pdt
  6.  
  7. >        saved process group ID
  8. >          An    active process has a saved process group ID that is
  9. >          set to the    saved process group ID of the parent
  10. >          process at    the time of creation of    the process (via
  11. >          the fork()    function).  It is reset    to the process
  12. >          group ID of the process when the process successfully
  13. >          calls one of the exec functions.
  14.  
  15. What is the significance of the "saved process group ID"?  How is
  16. it different to the normal process-group-ID?  Who uses it?
  17.  
  18. >        In section 3.2.2.2 Description of the _exit function replace
  19. >        the paragraph:
  20.  
  21. >        with:
  22. > 
  23. >          If    the process is a session process group leader, the
  24. >          SIGHUP signal may be sent to each process that has    a
  25.                ^^^ should be replaced by the word "will"
  26. >          process group ID equal to that of the calling process;
  27. >          also, all such processes may have their process group
  28. >          ID    set to zero.
  29. > 
  30. >          If    the implementation supports the    job control option
  31. >          and if the    calling    process    has child processes that
  32. >          are stopped, they will be sent SIGHUP and SIGCONT
  33. >          signals.
  34. > 
  35.  
  36. I disagree with the proposal on the handling of _exit processing for
  37. job control.  It should be possible to not have to know in advance
  38. that you wish to log-off and leave something running that you started
  39. in foreground and later shifted to background.  This is a KEY feature
  40. of job control.  
  41.  
  42. vhangup() will provide clean terminals on a bsd system,
  43. and we have improved vhangup further to not just turn off READ/WRITE bits,
  44. but to actually redirect the file references to /dev/null (which has
  45. the advantage of also dropping DTR reliably). 
  46. Infinite-loop processes don't cause problems with system-response because
  47. they are automatically niced (something that is long-needed in UNIX systems).
  48.  
  49. I see no mention of a vhangup equivalent in this proposal segment, but
  50. then again, I haven't seen the whole of P1003 either.
  51.  
  52. I find the SIGHUP being sent by exiting processes to sub-proceses
  53. a plain nuisance, and it does nothing for productivity.  Nohup(1)
  54. is effectively obsoleted by job control, since the process won't
  55. receive signals from terminals when they are in background anyway.
  56.  
  57. One if the KEY things about job-control is that you don't have
  58. to "know in advance" what you plan to do.  Nohup(1) requires that 
  59. you do known in advance, and with the above proposal, nohup(1) IS
  60. required if you want to leave jobs running when you log-off.
  61.  
  62. The SIGHUP and SIGCONT signals are only sent to processes in the
  63. terminal process group when modem carrier disappears on a BSD system.
  64. Children of init that are stopped are also sent SIGHUP's and SIGCONT's.
  65. Children of init that aren't stopped aren't sent anything.
  66.  
  67. Ian Donaldson
  68.  
  69. Volume-Number: Volume 7, Number 84
  70.  
  71.