[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2011-07-18 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

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).

--
nosy: +pitrou
versions: +Python 3.3 -Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2011-07-18 Thread Roundup Robot

Roundup Robot  added the comment:

New changeset 3fa7581f6d46 by Antoine Pitrou in branch '2.7':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under 
Windows.
http://hg.python.org/cpython/rev/3fa7581f6d46

New changeset a01ba3c32a4b by Antoine Pitrou in branch '3.2':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under 
Windows.
http://hg.python.org/cpython/rev/a01ba3c32a4b

New changeset aee7c27ea7df by Antoine Pitrou in branch 'default':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under 
Windows.
http://hg.python.org/cpython/rev/aee7c27ea7df

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2011-07-18 Thread Steve Hill

Steve Hill  added the comment:

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.

--
nosy: +steve_hill

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2010-02-09 Thread Brian Curtin

Changes by Brian Curtin :


--
priority:  -> normal
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2009-07-13 Thread Jose Fonseca

Jose Fonseca  added the comment:

Perhaps. I'm not a scons developer -- just an user -- and I don't know
what versions of python far back in time they want support, but it
appears it would make sense to use subprocess where available indeed. I
already I've filled an issue with scons at
http://scons.tigris.org/issues/show_bug.cgi?id=2449 and linked back to
this issue and I trust the developers to do whatever they see fit to
address this problem.

Instead of just marking this issue as won't fix, shouldn't at least some
documentation be added, or something sensible like that? In
http://docs.python.org/library/os.html#process-management os.spawn* are
not marked as deprecated -- just says that "the subprocess module
provides more powerful facilities" and is "preferable" --, and it
certainly doesn't say these functions are not thread safe. It would be a
pity if other users would have to invest as much time as I did to find
this race condition (it was rare, and happened in a build farm so we
couldn't see the windows access violation dialog), and multithreading is
getting more and more common.

Also, if the only reason not to fix this is the lack of a patch I don't
mind in producing one FWIW.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2009-07-13 Thread Amaury Forgeot d'Arc

Amaury Forgeot d'Arc  added the comment:

Indeed. But shouldn't you use the subprocess module instead?

--
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6476] MSVCRT's spawnve/spawnvpe are not thread safe

2009-07-13 Thread Jose Fonseca

New submission from Jose Fonseca :

MSVCRT's implementation of _spawnve, _spawnvpe, or any version that
takes an environ as paramater is not thread-safe, because it stores a
temporary environment string into a global variable.

_spawnve, _spawnvpe, and friends call a function named _cenvarg which
concatenate the environment strings into a global variable called
_aenvptr, which gets free'd and zero'd after each invocation.

This was causing random build failures in scons when parallel build (-j)
was enabled.

The sample application evidences this problem. It also includes a simple
workaround in python, by acquiring a global lock around os.spawnve, and
simulating P_WAIT with P_NOWAIT to avoid holding the global lock while
the child process is running. I believe something along these lines
should be done for CPython on Windows.

--
components: Interpreter Core
files: spawnve.py
messages: 90495
nosy: jfonseca
severity: normal
status: open
title: MSVCRT's spawnve/spawnvpe are not thread safe
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14495/spawnve.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com