Tom Culliton <[EMAIL PROTECTED]> added the comment: I'm not sure what the POSIX standards say on this (and MS-Windows may go it's own contrary way), but for most real systems the PID is a running count (generally 32 bit or larger today) which would have to cycle all the way around to repeat. It's actually done this way on purpose to provide the longest possible time between IDs getting reused. I suspect that having it cycle and reuse an ID isn't an issue in practice, and keeping a list of results leaves you with the problem of figuring out which PID 55367 they're talking about... Not to mention that if you're leaving child process results unchecked for long enough for the PID counter to cycle, there are other problems with the application. ;-)
Gregory P. Smith wrote: > Gregory P. Smith <[EMAIL PROTECTED]> added the comment: > > """Basically it's OK to collect > all the child exit codes if you record the results and return them when > requested. This would mean that waitpid and the like would have to check > a cached list of PIDs and exit statuses before actually waiting.""" > > note that this would still have problems. PIDs are recycled by the OS > so as soon as you've waited on one and the process dies, the OS is free > to launch a new process using it. If the new process happens to be > another one of ours launched by subprocess that would be a problem. > Make the cached map of pids -> exit codes be a map of pids -> [list of > exit codes] instead? > > _____________________________________ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1731717> > _____________________________________ > _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1731717> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com