How to get return values of a forked process

Discussion in 'Python' started by Ian, Jun 21, 2011.

  1. Ian

    Ian Guest

    Hello all,

    I need some helped with forking. In my script, I fork a process. I
    want to get return values from the child process.

    This is the script that does the forking:
    for x in (mylist):
    pid = os.fork()
    if pid:
    pidList.append(pid)
    else:
    os.execv('/usr/bin/python',('/usr/bin/
    python',myForkedScript))

    for pid in pidList:
    childPid, status = os.waitpid(pid,0)
    # I think status should be the return value of the forked
    process; I would expect status to be a 1 or a 0

    myForkedScript has code like this:
    if fail:
    os._exit(1)
    else:
    os._exit(os.EX_OK)


    Is using os._exit() the correct way to get a return value back to the
    main process?

    I thought the value 'n', passed in os._exit(n) would be the value I
    get returned. In the case of a failure, I get 256 returned rather
    than 1.

    Thanks for the assistance!
    IL
    Ian, Jun 21, 2011
    #1
    1. Advertising

  2. Ian

    Ian Kelly Guest

    On Tue, Jun 21, 2011 at 12:26 PM, Ian <> wrote:
    > myForkedScript has code like this:
    > if fail:
    > os._exit(1)
    > else:
    > os._exit(os.EX_OK)
    >
    > Is using os._exit() the correct way to get a return value back to the
    > main process?


    sys.exit() is the preferred way.

    > I thought the value 'n', passed in os._exit(n) would be the value I
    > get returned. In the case of a failure, I get 256 returned rather
    > than 1.


    According to the docs, on Unix:

    """
    Wait for completion of a child process, and return a tuple containing
    its pid and exit status indication: a 16-bit number, whose low byte is
    the signal number that killed the process, and whose high byte is the
    exit status (if the signal number is zero); the high bit of the low
    byte is set if a core file was produced.
    """

    And on Windows:

    """
    Wait for completion of a process given by process handle pid, and
    return a tuple containing pid, and its exit status shifted left by 8
    bits (shifting makes cross-platform use of the function easier).
    """

    (256 >> 8) == 1

    However, I would advise using the subprocess module for this instead
    of the os module (which is just low-level wrappers around system
    calls).
    Ian Kelly, Jun 21, 2011
    #2
    1. Advertising

  3. Ian

    Ian Guest

    On Jun 21, 1:54 pm, Ian Kelly <> wrote:
    > On Tue, Jun 21, 2011 at 12:26 PM, Ian <> wrote:
    > > myForkedScript has code like this:
    > > if fail:
    > >    os._exit(1)
    > > else:
    > >    os._exit(os.EX_OK)

    >
    > > Is using os._exit() the correct way to get a return value back to the
    > > main process?

    >
    > sys.exit() is the preferred way.
    >
    > > I thought the value 'n', passed in os._exit(n) would be the value I
    > > get returned.  In the case of a failure, I get 256 returned rather
    > > than 1.

    >
    > According to the docs, on Unix:
    >
    > """
    > Wait for completion of a child process, and return a tuple containing
    > its pid and exit status indication: a 16-bit number, whose low byte is
    > the signal number that killed the process, and whose high byte is the
    > exit status (if the signal number is zero); the high bit of the low
    > byte is set if a core file was produced.
    > """
    >
    > And on Windows:
    >
    > """
    > Wait for completion of a process given by process handle pid, and
    > return a tuple containing pid, and its exit status shifted left by 8
    > bits (shifting makes cross-platform use of the function easier).
    > """
    >
    > (256 >> 8) == 1
    >
    > However, I would advise using the subprocess module for this instead
    > of the os module (which is just low-level wrappers around system
    > calls).


    Where did you find the Unix docs you pasted in? I didn't find it in
    the man pages. Thank you. Based on what you say, I will change my
    os._exit() to sys.exit().
    Ian, Jun 21, 2011
    #3
  4. Ian

    Ian Kelly Guest

    > Where did you find the Unix docs you pasted in?  I didn't find it in
    > the man pages.  Thank you.  Based on what you say, I will change my
    > os._exit() to sys.exit().


    http://docs.python.org/library/os.html#os.wait
    http://docs.python.org/library/os.html#os.waitpid

    I don't know what man pages you were looking at, but the Unix system
    call does work the same way; to extract the exit status in C you're
    supposed to use the WEXITSTATUS(status) macro, which is typically
    implemented as ((status >> 8) & 0377). See:

    http://linux.die.net/man/2/waitpid
    Ian Kelly, Jun 21, 2011
    #4
  5. Ian

    Chris Torek Guest

    >> On Tue, Jun 21, 2011 at 12:26 PM, Ian <> wrote:
    >>> myForkedScript has code like this:
    >>> if fail:
    >>> os._exit(1)
    >>> else:
    >>> os._exit(os.EX_OK)
    >>>
    >>> Is using os._exit() the correct way to get a return value back to the
    >>> main process?


    "The" correct way, no, but it is "a" correct way (and cheaper than
    using a pipe to pickle and unpickle failure, the way the subprocess
    module does it, for instance). In any case, you *should* call
    os._exit() either directly or indirectly after a successful fork
    but a failed exec.

    >On Jun 21, 1:54 pm, Ian Kelly <> wrote:
    >> sys.exit() is the preferred way.


    Using sys.exit() after a fork() has other risks (principally,
    duplication of pending output when flushing write-mode streams),
    which is why os._exit() is provided.

    >>> I thought the value 'n', passed in os._exit(n) would be the value I
    >>> get returned.  In the case of a failure, I get 256 returned rather
    >>> than 1.


    >> According to the docs ...

    [snip documentation and description]
    >> However, I would advise using the subprocess module for this instead
    >> of the os module (which is just low-level wrappers around system
    >> calls).


    Indeed, subprocess gives you convenience, safety, and platform
    independence (at least across POSIX-and-Windows) with a relatively
    low cost. As long as the cost is low enough (and it probably is)
    I agree with this.

    In article <>
    Ian <> wrote:
    >Where did you find the Unix docs you pasted in? I didn't find it in
    >the man pages. Thank you. Based on what you say, I will change my
    >os._exit() to sys.exit().


    Not sure where Ian Kelly's documentation came from, but note that on
    Unix, the "os" module also provides os.WIFSIGNALED, os.WTERMSIG,
    os.WIFEXITED, and os.WEXITSTATUS for dissecting the "status"
    integer returned from the various os.wait* calls.

    Again, if you use the subprocess module, you are insulated from
    this sort of detail (which, as always, has both advantages and
    disadvantages).
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: gmail (figure it out) http://web.torek.net/torek/index.html
    Chris Torek, Jun 21, 2011
    #5
    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. RL
    Replies:
    2
    Views:
    586
  2. Replies:
    2
    Views:
    415
    Chris Croughton
    Apr 13, 2005
  3. John Lin
    Replies:
    19
    Views:
    555
    Donn Cave
    Sep 25, 2003
  4. James Colannino

    Detecting problems in a forked process

    James Colannino, Dec 29, 2005, in forum: Python
    Replies:
    2
    Views:
    302
    Donn Cave
    Dec 30, 2005
  5. Alexander N. Spitzer
    Replies:
    1
    Views:
    524
    Lawrence Kirby
    Nov 12, 2004
Loading...

Share This Page