Reading output from a child process non-blockingly

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Yuan HOng

    Reading output from a child process non-blockingly

    In my program I have to call an external program and parse its output.
    For that I use the os.popen2 function, and then read the output
    stream.

    But the complexity is that the external program gives back its output
    in a piecemeal manner, with long delays between the outputs. In the
    main program I want to therefore read the output in a non-blocking
    manner, to read as many bytes as the child process is spitting out.

    The question is, how can I achieve that?

    I tried use select.select on the output stream returned by os.popen2,
    but it returns a readable file descriptor only after the whole child
    process ends.

    Here is a script simulating the external program:

    test.py:
    import sys, time
    print 'hello\n'*500
    sys.stdout.flus h()
    time.sleep(100)
    print 'world\n'*500

    And here is what I am tring to do in the main program to read its output:

    import os, select
    cmd = 'python test.py'
    pin, pout = os.popen2(cmd)
    while not select.select([pout], [], [], some_timeout)[0]:
    pass
    pout.readline()

    I hope to get the first return very soon, before the external program
    sleeps, but instead only after the whole program exits do I get any
    output.

    Can anyone give me a hint?

    --
    Hong Yuan

    $BBg4I2Hf&>e7z :`D6;T(B

  • ilochab@gmail.com

    #2
    Re: Reading output from a child process non-blockingly



    Yuan HOng ha scritto:[color=blue]
    > In my program I have to call an external program and parse its output.
    > For that I use the os.popen2 function, and then read the output
    > stream.
    >
    > But the complexity is that the external program gives back its output
    > in a piecemeal manner, with long delays between the outputs. In the
    > main program I want to therefore read the output in a non-blocking
    > manner, to read as many bytes as the child process is spitting out.
    >
    > The question is, how can I achieve that?
    >[/color]

    What about using a thread to control the child process?

    Licia

    Comment

    • Thomas Guettler

      #3
      Re: Reading output from a child process non-blockingly

      Am Wed, 29 Jun 2005 16:08:54 +0800 schrieb Yuan HOng:
      [color=blue]
      > In my program I have to call an external program and parse its output.
      > For that I use the os.popen2 function, and then read the output
      > stream.[/color]
      [cut][color=blue]
      > I tried use select.select on the output stream returned by os.popen2,
      > but it returns a readable file descriptor only after the whole child
      > process ends.[/color]

      Select is the right module for this. But it only works on file descriptors
      on unix.

      What happens, if you run the external command on the shell like this:

      ext_prog > out.log &

      Check out.log with "tail" or "less +F". Do you see the data appear
      in small chunks? If not, the application detects that stdout is not
      a tty and you only get data if the buffer is full or if the application
      ends.

      If out.log gets filled in chunks you want to read, you can read this file
      as long as the application is running. Remember the size of the file after
      each read and use fd.seek() to read only the new data after opening it
      again. This should work on windows, too.

      HTH,
      Thomas

      --
      Thomas Güttler, http://www.thomas-guettler.de/


      Comment

      • Dan Sommers

        #4
        Re: Reading output from a child process non-blockingly

        On Wed, 29 Jun 2005 15:45:20 +0200,
        Thomas Guettler <guettli@thom as-guettler.de> wrote:
        [color=blue]
        > Check out.log with "tail" or "less +F". Do you see the data appear in
        > small chunks? ...[/color]

        You'll need "tail -f", I think.

        Regards,
        Dan

        --
        Dan Sommers
        <http://www.tombstoneze ro.net/dan/>

        Comment

        Working...