home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0018.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.9 KB  |  70 lines

  1. Submitted-by: davis@unidata.ucar.edu (Glenn P. Davis)
  2.  
  3. I have a program which demulplexes input and hands it out to
  4. various child processes. The child process can be anything that
  5. reads from stdin and terminate up reading EOF. The parent
  6. calls pipe(), fork(), dup() (actually dup2()), close() and
  7. execve() in the usual idiomatic way.
  8.  
  9. The only thing slightly unusual about the program is that is
  10. maintains a list of data structures representing each subprocess,
  11. effectively maintaining open pipe connections to multiple running children.
  12. This list has a maximum size and if a new connection child needs to be
  13. created, then the least recently used connection is closed and
  14. the associated resources recycled.
  15.  
  16. This is where the problem comes in, and I don't understand what is
  17. going on. I'm working under SunOS 4.1.1.
  18. The sequence of calls is
  19.  
  20.     close(child->pipe_file_descriptor) ;
  21.     waitpid(child->process_id, &status, 0) ; /* Blocks til child exits */
  22.  
  23. What I am seeing is that the child blocks waiting for input
  24. instead of reading EOF, and the parent blocks in waitpid() --> deadlock.
  25. 'ps -l' reports both processes sleeping (STAT S), with the parent WCHAN
  26. as "child" and the child's as "socket". This is true if a call to sleep()
  27. is placed between close() and waitpid().
  28.  
  29. The problem does not occur if the child is the "most recently opened".
  30. If I set the list maximum size down to 1, things work properly:
  31. the child reads EOF after the parent close() and exits,
  32. the parent waitpid() returns and we proceed.
  33. When I shutdown all descriptors sequentially from the Most Recently Used to
  34. the Least Recently Used, as occurs in normal parent program shutdown, things
  35. work properly.
  36.  
  37. Some interesting observations can be made if the waitpid call is changed
  38. to
  39.     waitpid(-1, &status, WNOHANG) ; /* Don't Block, reap any child */
  40.  
  41. The parent program now proceeds.  There is logic in the main loop of the
  42. parent to close the least recently used connection if there was no input
  43. in a time interval. Thus all output channels will be closed after some
  44. number of timeouts with no input. While this is going on, 'ps' reports
  45. all children sleeping, waiting for input until the most recently used
  46. connection is closed. At this point, all of the children start reporting
  47. EOF and exiting, starting with the most recently used!
  48.  
  49. ------
  50.  
  51. So, what is going on here? My major concern is that the child processes
  52. are not able to detect EOF in a timely manner after the close of the parent
  53. end of the pipe. Asynchronous wait() 'ing does not really solve the problem:
  54. in the presence of continuous input there is an accumlation of child processes
  55. until system resources such as process table entries or memory are exhausted.
  56. Am I misunderstanding something or is this an OS bug?
  57.  
  58. Please reply directly.
  59.  
  60. Thanks.
  61.  
  62. Glenn P. Davis
  63. UCAR / Unidata
  64. PO Box 3000                   3300 Mitchell Lane, Suite 170
  65. Boulder, CO 80307-3000        Boulder, CO  80301
  66. (303) 497 8643
  67.  
  68. Volume-Number: Volume 28, Number 18
  69.  
  70.