File name |
Uploaded |
Description |
Edit |
mydiffs.diff
|
janglin,
2009-07-01 15:08
|
diff of posixmodule.c and os.rst combined |
|
Issue6394-1.diff
|
janglin,
2009-07-01 19:36
|
diff of posixmodule.c and os.rst combined |
|
Issue6394-2.diff
|
janglin,
2009-07-02 14:23
|
diff of posixmodule.c and os.rst combined |
|
test_os.diff
|
janglin,
2010-09-07 19:16
|
diff test_os.py with unit test for os.getppid |
|
6394.diff
|
janglin,
2010-09-07 20:01
|
diff against the current py3k svn branch |
|
msg89981 - (view) |
Author: Jon Anglin (janglin) |
Date: 2009-07-01 15:08 |
Implements getppid in the os module on Windows systems. The getppid
function was only available on Unix like systems, this diff patch brings
this functionality to Windows systems. This function will return the
parent process Id, upon error it will return -1. This differs from the
Unix implementation that never fails. Due to the way Windows returns the
parent process Id, a never fail guarantee can not be made. It should only
fail in low memory conditions. This patch is on the latest svn trunk (
http://svn.python.org/projects/python/trunk). This implementation should
port to any python version (older or newer). I have personally tested it
against Python 2.5.4, 2.6.2, 3.1, and the aforementioned svn trunk.
|
msg89983 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-07-01 15:11 |
I'm not qualified to comment on Windows-specific code, but two things:
- you should raise an appropriate exception on failure, not return -1
- the file is intended with tabs, not spaces
|
msg89984 - (view) |
Author: Jon Anglin (janglin) |
Date: 2009-07-01 15:42 |
I didn't raise an exception because the Unix version never fails (or raises) so I thought to maintain compatibility I would always return a value. Do you advise that I should change it?
As for the tabs... This entire process is new to me and I am learning, it was just a mistake.
|
msg89995 - (view) |
Author: Jon Anglin (janglin) |
Date: 2009-07-01 19:36 |
Implements getppid in the os module on Windows systems. The getppid
function was only available on Unix like systems, this diff patch brings
this functionality to Windows systems. This function will return the
parent process Id, upon error it raises a WindowsError. This differs
from the Unix implementation that never fails. Due to the way Windows
returns the parent process Id, a never fail guarantee can not be made.
This is a revision of a previous post. The file Issue6394-1.diff
contains the updated patches.
|
msg90001 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2009-07-02 08:14 |
First, I checked that the API does exist on Window 2000. And python does
not have any "never fail guarantee", specially in low memory conditions.
Then, some remarks:
- If Process32First or Process32Next fail for any reason, "return
win32_error(...)" is called, but the GetLastError function won't find
the cause because CloseHandle will clear it.
- It would be nice to add a comment like "if the loop ends and our pid
was not found, GetLastError() will return ERROR_NO_MORE_FILES. This is
an error anyway, so let's raise this."
- A unit test is necessary: it could use a subprocess and compare
getpid() with the child's getppid().
- The documentation should state what happens when the parent process
exits. Is the ppid reset to zero? Is it possible to have another new
process with the same ppid?
|
msg90012 - (view) |
Author: Jon Anglin (janglin) |
Date: 2009-07-02 14:23 |
I have addressed the issues brought up by Amaury Forgeot d'Arc except
for the unit test. I will get a unit test in tommorrow. Thank you for
the feedback. I have uploaded a new diff file Issue6394-2.diff.
- Should I remove the old diff files?
I ran some test with a parent process that had exited. The code still
returned the correct parent process id, even though the process does
not exist. I am not sure if process ids get recycled, but I am looking
in to it.
|
msg90017 - (view) |
Author: Jon Anglin (janglin) |
Date: 2009-07-02 14:59 |
Just some information, on Windows:
- process ids are re-used.
- parent process id is set at process creation time and never updated.
(Windows Internal 4th Ed. by Russinovich and Solomon).
Thus, I would say that a long running process can not rely on the value
of its parent process id. The parent may not be running, or the process
id may have been re-used and the process with that id may not be in fact
the actual parent. Having said that, I don't know the algorithm that
Windows uses for process ids, so collisions may be rare (or not).
-Do these same issues exist on Unix systems?
|
msg90020 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2009-07-02 15:24 |
> Do these same issues exist on Unix systems?
No. When the parent exits, the child process is attached to the 'init'
process and getppid() returns 1.
And collisions are not rare at all. Actually it seems that you get the
same pid if you close and restart a program quickly.
That's why Windows apps prefer dealing with "process handles" instead of
"process ids"
|
msg115797 - (view) |
Author: Jon Anglin (janglin) |
Date: 2010-09-07 19:16 |
Here is a unit test for os.getppid on Windows. The test_os.diff file is the diff of the Lib/test/test.os.py file from the py3k svn branch.
|
msg115799 - (view) |
Author: Jon Anglin (janglin) |
Date: 2010-09-07 20:01 |
I have uploaded a new diff file (from the py3k svn trunk) that has all of the changes in Doc/library/os.rst, Modules/posixmodule.c, and Lib/test/test_os.py. It is called 6394.diff. Let me know if I can do anything else to make this happen.
|
msg115803 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-09-07 20:19 |
I'm currently working on it. I'll certainly commit it shortly with a few changes:
- no need to say that a function fails with WindowsError, at least in the docstring.
- return error sooner to reduce indentation.
- in tests, use subprocess instead of multiprocessing.
- other minor formatting nits.
|
msg115808 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2010-09-07 21:33 |
Committed r84601. Thanks for the patch and your perseverance!
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:50 | admin | set | github: 50643 |
2010-09-07 21:33:41 | amaury.forgeotdarc | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
2010-09-07 21:33:16 | amaury.forgeotdarc | set | messages:
+ msg115808 |
2010-09-07 20:19:02 | amaury.forgeotdarc | set | messages:
+ msg115803 |
2010-09-07 20:01:13 | janglin | set | files:
+ 6394.diff
messages:
+ msg115799 |
2010-09-07 19:16:32 | janglin | set | files:
+ test_os.diff
messages:
+ msg115797 |
2010-09-04 00:27:28 | pitrou | set | nosy:
+ tim.golden, brian.curtin stage: patch review
versions:
+ Python 3.2, - Python 2.7 |
2009-07-02 15:24:45 | amaury.forgeotdarc | set | messages:
+ msg90020 |
2009-07-02 14:59:37 | janglin | set | messages:
+ msg90017 |
2009-07-02 14:23:06 | janglin | set | files:
+ Issue6394-2.diff
messages:
+ msg90012 |
2009-07-02 08:14:09 | amaury.forgeotdarc | set | nosy:
+ amaury.forgeotdarc messages:
+ msg90001
|
2009-07-01 19:36:55 | janglin | set | files:
+ Issue6394-1.diff
messages:
+ msg89995 |
2009-07-01 15:42:03 | janglin | set | messages:
+ msg89984 |
2009-07-01 15:11:53 | pitrou | set | nosy:
+ pitrou messages:
+ msg89983
|
2009-07-01 15:08:08 | janglin | create | |