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 steve_hill
Recipients amaury.forgeotdarc, jfonseca, steve_hill
Date 2011-07-18.13:22:07
SpamBayes Score 3.743894e-12
Marked as misclassified No
Message-id <1310995328.83.0.996738547322.issue6476@psf.upfronthosting.co.za>
In-reply-to
Content
Why has this bug been resolved as "won't fix"? It seems to me that this is a valid issue with something that has not been deprecated, yet it has been decided neither to fix it (despite there being an offer by the originator to submit a patch) nor even to document the deficiency.

We've been using SCons for the last 3-4 years, during which time we have been plagued by this issue - more so as multi-core machines have become more prevalent. There was a thread on the SCons Users mailing list in March '09, which stopped short of diagnosing the problem and we've lived with it ever since - putting it down to Python being "a bit flaky". I now discover that it is an issue that has been diagnosed two years ago and deliberately left in the implementation of the language. Simply saying "you should use subprocess" is not helpful; SCons at that time was supporting all Python versions back to 2.0 (possibly earlier) so couldn't rely on the subprocess module being present.

Ideally, it should be worked-around so that these functions can safely be used on all platforms without requiring mutual exclusion in the application. However, it seems to me that, at a bare minimum, it should be documented that these functions are not thread safe under Windows.
History
Date User Action Args
2011-07-18 13:22:09steve_hillsetrecipients: + steve_hill, amaury.forgeotdarc, jfonseca
2011-07-18 13:22:08steve_hillsetmessageid: <1310995328.83.0.996738547322.issue6476@psf.upfronthosting.co.za>
2011-07-18 13:22:08steve_hilllinkissue6476 messages
2011-07-18 13:22:07steve_hillcreate