New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSVCRT's spawnve/spawnvpe are not thread safe #50725
Comments
MSVCRT's implementation of _spawnve, _spawnvpe, or any version that _spawnve, _spawnvpe, and friends call a function named _cenvarg which This was causing random build failures in scons when parallel build (-j) The sample application evidences this problem. It also includes a simple |
Indeed. But shouldn't you use the subprocess module instead? |
Perhaps. I'm not a scons developer -- just an user -- and I don't know Instead of just marking this issue as won't fix, shouldn't at least some Also, if the only reason not to fix this is the lack of a patch I don't |
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. |
New changeset 3fa7581f6d46 by Antoine Pitrou in branch '2.7': New changeset a01ba3c32a4b by Antoine Pitrou in branch '3.2': New changeset aee7c27ea7df by Antoine Pitrou in branch 'default': |
I've made the necessary doc changes. I leave it open because I'm not sure what to do with the bugfix request (I agree with the general suggestion to use subprocess instead, though). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: