Author tom_culliton
Recipients abo, astrand, dsagal, gjb1002, gregory.p.smith, gvanrossum, nnorwitz, tom_culliton
Date 2008-03-24.16:56:58
SpamBayes Score 0.00440605
Marked as misclassified No
Message-id <47E7DCEE.10705@oracle.com>
In-reply-to <1206031211.3.0.660181022947.issue1731717@psf.upfronthosting.co.za>
Content
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>
> _____________________________________
>
History
Date User Action Args
2008-03-24 16:57:03tom_cullitonsetspambayes_score: 0.00440605 -> 0.00440605
recipients: + tom_culliton, gvanrossum, nnorwitz, abo, gregory.p.smith, astrand, gjb1002, dsagal
2008-03-24 16:56:59tom_cullitonlinkissue1731717 messages
2008-03-24 16:56:58tom_cullitoncreate