[OT?] kid's output stuck in a TTY?!

Discussion in 'Perl Misc' started by Ilya Zakharevich, Jul 13, 2010.

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

    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.

    However, what I observe is that the kid's output to TTY is
    interdispersed with output from the next kid, and is interdispersed
    with output to TTY from the parent. (Parent does not open TTY, it
    just writes to STDERR which happens to be TTY.)

    It looks like the output of kid is somehow "stuck" in a TTY (and it
    writes whole lines!) for some time after the kid terminates. (Doing
    `sleep 1' in a parent IS a workaround...)

    The system is

    Linux foo 2.6.18-194.3.1.el5PAE #1 SMP Thu May 13 13:48:44 TZ 2010
    i686 athlon i386 GNU/Linux

    Is it expected somehow?

    Thanks,
    Ilya

    P.S. Test script is available, but it is somewhat convoluted since I
    was testing for some OTHER problems. ;-) :-(
    Ilya Zakharevich, Jul 13, 2010
    #1
    1. Advertising

  2. Ilya Zakharevich <> 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
    Peter Makholm, Jul 13, 2010
    #2
    1. Advertising

  3. On 2010-07-13, Ben Morrow <> wrote:
    > Quoth Peter Makholm <>:
    >> 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
    Ilya Zakharevich, Jul 13, 2010
    #3
  4. On 2010-07-13, Ben Morrow <> wrote:
    >
    > Quoth Ilya Zakharevich <>:
    >> On 2010-07-13, Ben Morrow <> 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
    Ilya Zakharevich, Jul 14, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug Mitchell
    Replies:
    6
    Views:
    389
  2. BORT
    Replies:
    38
    Views:
    1,308
    =?iso-8859-1?B?QW5kcuk=?=
    Jul 2, 2005
  3. Adriaan Renting
    Replies:
    1
    Views:
    325
    Roy Smith
    Jun 28, 2005
  4. infidel

    threadsafety in cherrypy with kid

    infidel, Aug 18, 2005, in forum: Python
    Replies:
    0
    Views:
    286
    infidel
    Aug 18, 2005
  5. Brandon K

    Confused on Kid

    Brandon K, Oct 10, 2005, in forum: Python
    Replies:
    2
    Views:
    305
    Damjan
    Oct 25, 2005
Loading...

Share This Page