From: Peter Makholm on
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

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
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

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
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