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 <greg@krypto.org> 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 <report@bugs.python.org>
> <http://bugs.python.org/issue1731717>
> _____________________________________
>