This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rnk
Recipients abbot, astrand, brian.curtin, dmalcolm, filippo, giampaolo.rodola, guettli, orsenthil, pitrou, r.david.murray, rnk, srid
Date 2010-07-16.15:38:56
SpamBayes Score 0.003194769
Marked as misclassified No
Message-id <1279294743.62.0.436011812335.issue5673@psf.upfronthosting.co.za>
In-reply-to
Content
I forgot that I had to tweak the test as well as subprocess.py.  I did a .replace('\r', ''), but universal newlines is better.

Looking at the open questions I had about the Windows threads, I think it'll be OK if the user follows the pattern of:
proc = subprocess.Popen(...)
try:
    stdout, stderr = proc.communicate(timeout=...)
except subprocess.TimeoutExpired:
    proc.kill()
    stdout, stderr = proc.communicate()

If the child process is deadlocked and the user doesn't kill it, then the file descriptors will be leaked and the daemon threads will also live on forever.  I *think* that's the worst that could happen.  Or they could of course wakeup during interpreter shutdown and cause tracebacks, but that's highly unlikely, and already possible currently.

Anyway, I would say we can't avoid leaking the fds in that situation, because we can't know if the user will eventually ask us for the data or not.  If they want to avoid the leak, they can clean up after themselves.

What's the next step for getting this in?  Thanks to those who've taken time to look at this so far.
History
Date User Action Args
2010-07-16 15:39:03rnksetrecipients: + rnk, guettli, astrand, orsenthil, pitrou, giampaolo.rodola, abbot, r.david.murray, brian.curtin, srid, dmalcolm, filippo
2010-07-16 15:39:03rnksetmessageid: <1279294743.62.0.436011812335.issue5673@psf.upfronthosting.co.za>
2010-07-16 15:39:01rnklinkissue5673 messages
2010-07-16 15:39:00rnkcreate