home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / internal / 1789 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!thisbe.Eng.Sandy.Novell.COM!terry
  2. From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
  3. Newsgroups: comp.unix.internals
  4. Subject: Re: How can a Unix process put itself in background?
  5. Message-ID: <BuDo18.1M9@Novell.COM>
  6. Date: 10 Sep 92 19:41:31 GMT
  7. References: <lma.716056953@dayton.Stanford.EDU> <lma.716092591@dayton.Stanford.EDU>
  8. Sender: usenet@Novell.COM (Usenet News)
  9. Organization: Novell NPD -- Sandy, UT
  10. Lines: 51
  11. Nntp-Posting-Host: thisbe.eng.sandy.novell.com
  12.  
  13. In article <lma.716092591@dayton.Stanford.EDU> lma@dayton.Stanford.EDU (Larry Augustin) writes:
  14. >lma@dayton.Stanford.EDU (Larry Augustin) writes:
  15. >
  16. >>Someone stopped by my office with this question yesterday.
  17. >
  18. >>A user invokes a program at the shell, and interacts with the program
  19. >>for a short time.  Eventually the user selects some "quit" option of
  20. >>the program.  Before the program really quits, it wants to go off and
  21. >>spend a minute or two checking some database files on disk.  Is there
  22. >>any way for the program to return control to the user's shell while it
  23. >>does the background stuff?  In effect, the program wants to "detach"
  24. >>itself from stdin/stdout, return control to the shell, and continue in
  25. >>background for a while before exiting.
  26. >
  27. >>The only solutions we could come up with were based on forking a child
  28. >>to do the background part.  is this the only way to do it?  Is there a
  29. >>solution that does not need a fork?
  30.  
  31.  
  32. Have you tried this to wake the shell up?
  33.  
  34.     kill( getppid(), SIGCHLD);
  35.  
  36. This is pretty bogus, and I assume that you have a good reason for not using
  37. a "fork()" where the child dissociates (becomes a child of init) and the
  38. parent returns to satisfy the wait(4).
  39.  
  40. This works on some machines, and not on others, and the values returned for
  41. the exit status of the child from the wait4 are bound to be incorrect
  42. (unless you link with -lprognosticate 8-) 8-)), and this isn't guaranteed
  43. to not crash your shell.  But it's about the only way to make the shell
  44. "forget" about a subprocess (by interrupting the mechanism it uses to do
  45. it's "remembering").  The specific reason it may not work is dependant
  46. on how the "wait for child death" code is written and the actuality
  47. itself trapped in the shell.  Cruddy shells (shells which can miss a
  48. child completing if the child exits when multiple background tasks
  49. occur at around the same time) will probably let you get away with it.
  50.  
  51. The correct way is to use fork() as part of the procedure.  If you'll tell
  52. us why you don't want to use fork(), perhaps someone in the group can
  53. tell you why the reasoning is invalid, and suggest a workaround to the
  54. problem you think you have with fork()?
  55.  
  56.  
  57.                     Terry Lambert
  58.                     terry_lambert@gateway.novell.com
  59.                     terry@icarus.weber.edu
  60.  
  61. ---
  62. Disclaimer:  Any opinions in this posting are my own and not those of
  63. my present or previous employers.
  64.