laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
You are connecting to both stdin & stdout, but never processing stdout. Consequently, if the child process produces any output, it will eventually fill the pipe that you are not reading and the OS will block the child from writing anymore until you do something in the parent to reduce the content of the pipe. The number of iterations it will run will depend upon the amount of output produced by the child. Ie. How quickly it fills the pipe buffer. Eg. In the following which just echos the 'some command's it reads, the iteration count gets to 83 before it blocks.
83 * 13 = 1079, suggesting roughly a 1k buffer. Reduce the output to a single char:
This time the iteration count gets to 553, which means that the size of the buffer is a little more complicated. But if you process the output from the child within the parent's loop:
Now the loop happily runs for as long as you care to leave it running. The OS is simply protecting you from yourself, by preventing you from consuming all your memory by filling a pipe with output that you are never processing. Note: I used the non-blocking sysread to process the output as the child process is never producing newlines, so <READ> or read would block. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In reply to Re: open2() in Windows
by BrowserUk
|
|