home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / internal / 1801 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  2.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.unix.internals
  4. Subject: Re: How can a Unix process put itself in background?
  5. Date: 12 Sep 1992 02:49:08 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 32
  8. Message-ID: <18rlr4INNi23@early-bird.think.com>
  9. References: <1992Sep11.170405.28836@tandem.com> <18qopsINN12n@early-bird.think.com> <1992Sep11.222546.3878@tandem.com>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <1992Sep11.222546.3878@tandem.com> norcott_bill@tandem.com  (Bill Norcott) writes:
  13. >In article <18qopsINN12n@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
  14. >|> You still have to fork first, as the shell (or whatever process started the
  15. >|> program) waits for the original process to exit.
  16. >
  17. >Sure, all UNIX user processes are created by fork().  So the process
  18. >that wants to put itself into the background was created by fork().
  19. >And it's parent should be using waidpid() or wait() to wait for the
  20. >death of the child.  But the original question was, how can the guy's
  21. >existing (child) process put ITSELF in the background.  This is where
  22. >setsid() and setpgid() are used.
  23.  
  24. A background process is one that runs in parallel with the one that
  25. originally created it.  The child process has to fork() a grandchild, so
  26. that the child can exit(), which will cause the parent's wait() to return
  27. and allow it to continue processing.  Simply calling setsid() and setpgid()
  28. won't cause the parent's wait() or waitpid() to return.
  29.  
  30. The only thing that setsid() and setpgid() do is dissociate the process
  31. from the original process group.  And process groups only affect signal
  32. handling.  For instance, if the child calls setpgid(), and then the phone
  33. line is hung up, the child process won't receive a SIGHUP because it's no
  34. longer in the controlling terminal's process group.  So, whether it's
  35. appropriate to call setsid() or setpgid() depends on whether you want the
  36. background process to be immune to signals from the terminal (depending on
  37. what you're doing, you may actually want a background process to be killed
  38. when you hang up -- consider a program like leave(1)).
  39. -- 
  40. Barry Margolin
  41. System Manager, Thinking Machines Corp.
  42.  
  43. barmar@think.com          {uunet,harvard}!think!barmar
  44.