From: Peter Makholm on 13 Jul 2010 05:50 Ilya Zakharevich <nospam-abuse(a)ilyaz.org> writes: > I'm starting a kid, kid writes something to TTY (which is explicitely > opened in the kid). The kid also writes something to a pipe open()ed > to a parent. So the child process is doing something like open my $fh, ">", "/dev/tty"; ? > parent closes the pipe opened to the kid (opened via > open F, "@kid_cmd 2>&1 |"... > ). My assumption is that at this moment, all the traces of kid > existence should disappear. I would not expect closing this file handle to have eny other effect on the child than it's STDOUT would now point to a closed pipe, which would mean that any attempt to write to STDOUT would result in a SIGPIPE. I would neither expect it to kill the child process or to have eny effect on other file handles the child process might have opened. > Is it expected somehow? Yes, if you explicitly opens a filehandle to /dev/tty I believe this is to be expected. //Makholm
From: Ben Morrow on 13 Jul 2010 08:17 Quoth Peter Makholm <peter(a)makholm.net>: > Ilya Zakharevich <nospam-abuse(a)ilyaz.org> writes: > > > I'm starting a kid, kid writes something to TTY (which is explicitely > > opened in the kid). The kid also writes something to a pipe open()ed > > to a parent. > > So the child process is doing something like > > open my $fh, ">", "/dev/tty"; > > ? > > > parent closes the pipe opened to the kid (opened via > > open F, "@kid_cmd 2>&1 |"... > > ). My assumption is that at this moment, all the traces of kid > > existence should disappear. > > I would not expect closing this file handle to have eny other effect > on the child than it's STDOUT would now point to a closed pipe, which > would mean that any attempt to write to STDOUT would result in a > SIGPIPE. > > I would neither expect it to kill the child process or to have eny > effect on other file handles the child process might have opened. Closing a piped-open filehandle will wait for the child, so once close has returned the child will have exitted. (This may of course take some time if the child isn't killed by SIGPIPE.) > > Is it expected somehow? > > Yes, if you explicitly opens a filehandle to /dev/tty I believe this > is to be expected. It's not what I see here, at least with a simple test. If I run my $K; unless (open $K, "-|") { warn "kid: $$"; open my $T, ">", "/dev/tty"; print $T "one two three\n"; sleep 4; print $T "four five six\n"; exit 22; } close $K; warn +($?>>8) . ": seven eight nine"; I consistently get the parent waiting for the child to finish before continuing. Ilya: can you try that code, to see if you see the same behaviour? Ben
From: Ilya Zakharevich on 13 Jul 2010 17:20 On 2010-07-13, Ben Morrow <ben(a)morrow.me.uk> wrote: > Quoth Peter Makholm <peter(a)makholm.net>: >> So the child process is doing something like >> >> open my $fh, ">", "/dev/tty"; >> >> ? Yes. > Closing a piped-open filehandle will wait for the child, so once close > has returned the child will have exitted. (This may of course take some > time if the child isn't killed by SIGPIPE.) The kid just runs off the end of the script. Hmm, another thing I missed in my description: kid writes 3 bytes to its end of the pipe (STDOUT), and parent reads it all before close()ing. > It's not what I see here, at least with a simple test. If I run > > my $K; > unless (open $K, "-|") { > warn "kid: $$"; > open my $T, ">", "/dev/tty"; > print $T "one two three\n"; > sleep 4; > print $T "four five six\n"; > exit 22; > } > close $K; > warn +($?>>8) . ": seven eight nine"; > > I consistently get the parent waiting for the child to finish before > continuing. Ilya: can you try that code, to see if you see the same > behaviour? Looks normal: kid: 2743 at ./foo.pl line 3. one two three four five six 22: seven eight nine at ./foo.pl line 11. ====== I put the script to ilyaz.org/software/tmp/run_redir.pl I run it as perl ./run_redir.pl 1 > ! nu perl ./run_redir.pl > ! nu The version with 1 sleep()s, and "--"-delimited groups have duplicated output (as expected). Without `1', "--"-delimited groups are different, which I interpret as "--" being written at wrong order... Puzzled, Ilya
From: Ben Morrow on 13 Jul 2010 17:45 Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>: > On 2010-07-13, Ben Morrow <ben(a)morrow.me.uk> wrote: > > > Closing a piped-open filehandle will wait for the child, so once close > > has returned the child will have exitted. (This may of course take some > > time if the child isn't killed by SIGPIPE.) > > The kid just runs off the end of the script. Hmm, another thing I > missed in my description: kid writes 3 bytes to its end of the pipe > (STDOUT), and parent reads it all before close()ing. Another thing you missed: you are forking twice (a child of a child). AFAICT (I can't follow exactly what it's supposed to be doing) explicitly closing P in the child (which is the handle to the pipe to the grandchild) appears to fix the problem. Certainly, it stops any output from appearing after the (grand-)parent has exitted. Ben
From: Ilya Zakharevich on 14 Jul 2010 00:44 On 2010-07-13, Ben Morrow <ben(a)morrow.me.uk> wrote: > > Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>: >> On 2010-07-13, Ben Morrow <ben(a)morrow.me.uk> wrote: >> >> > Closing a piped-open filehandle will wait for the child, so once close >> > has returned the child will have exitted. (This may of course take some >> > time if the child isn't killed by SIGPIPE.) >> >> The kid just runs off the end of the script. Hmm, another thing I >> missed in my description: kid writes 3 bytes to its end of the pipe >> (STDOUT), and parent reads it all before close()ing. > > Another thing you missed: you are forking twice (a child of a child). Good idea! So it is the grandchild which writes to TTY, while may implicit wait() waits for the child! No wonder that grandchild has not yet terminate when the child does... A lot of thanks... > AFAICT (I can't follow exactly what it's supposed to be doing) Ha! It is just an initial prototype of a framework to test running Perl with some of STDIN/etc closed. To make it real, I'm afraid I need yet another parent/child layer on top of this... Yours, Ilya
|
Pages: 1 Prev: FAQ 1.5 What was Ponie? Next: FAQ 8.46 What's the difference between require and use? |