>> On Tue, Jun 21, 2011 at 12:26 PM, Ian <ian.l...@rocketmail.com> 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 <ian.g.ke...@gmail.com> 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 <d195a74d-e173-4168-8812-c03fc02e8...@fr19g2000vbb.googlegroups.com> Ian <ian.l...@rocketmail.com> 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
-- http://mail.python.org/mailman/listinfo/python-list
