[issue1983] Return from fork() is pid_t, not int
Ryan Stutsman stuts...@stanford.edu added the comment: No, I don't think this is actually fixed in any version of Python at the moment. The title may be a bit misleading, because all the versions now store the result of fork in a pid_t and return it as a PyLong. However, posix_waitpid is still pulling pid's as a PyInt. Changing this to PyLong would probably work for our purposes, but I guess the hangup was that in reality pid_t is supposed to be an opaque datatype and implementing it in CPython is non-trivial and has little benefit. Perhaps we close this as won't fix or I can create a patch to at least give a hack for 64-bit pid's but still treated as a long. -- nosy: +rstutsman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1983] Return from fork() is pid_t, not int
Ryan Stutsman added the comment: Actually the current trunk of as of this morning (60484) is still broken in a couple of ways. First, converting the pid_t using PyInt is a problem and second the waitpids aren't corrected. This would cause waits on invalid pids. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1983 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1983] Return from fork() is pid_t, not int
New submission from Ryan Stutsman: In current trunk (60097). Return from fork is not int but pid_t. Treating this as an int causes total breakage on systems with 64-bit pids. -- components: Library (Lib) messages: 61926 nosy: stutsman severity: normal status: open title: Return from fork() is pid_t, not int versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1983 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1983] Return from fork() is pid_t, not int
Ryan Stutsman added the comment: Yeah; I shuold be able to provide one. I just hacked 2.4.4 to work so I think I could provide a fix easily. The version I put together here is rough, so I'll try to create a cleaner solution tonight or this weekend. HiStar does (http://www.scs.stanford.edu/histar/). Not sure if it's better to test for pid_t (in configure) or just use a long long value all around a punt the problem? I'll probably just go with the former unless there are objections. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1983 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1983] Return from fork() is pid_t, not int
Ryan Stutsman added the comment: IIUC, HiStar is available in a 32-bit version, too, yet it may still use a 64-bit pid_t (Ryan, can you confirm whether that's the case?). Great point. pid_t is always 64-bit on HiStar. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1983 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
