Agreed, mixing the two abstractions doesn't work so great. I don't recall the exact use case for accessing the Popen object -- maybe there isn't one? In that case it's an easy decision. Otherwise we may have to document what you are allowed to do with the Popen object -- or else provide a new API to handle the use case (if there is one -- I expect there isn't one though).
The code change doesn't have to be dealt with before RC1 (you can just rip it out of the docs). On Sat, Feb 8, 2014 at 5:37 PM, Victor Stinner <[email protected]>wrote: > Hi, > > I found race conditions between Process (asyncio.subprocess) and Popen > (subprocess). Maybe we should drop Process.subprocess attribute to > reduce the risk of misuse of the API? > > Details: > > While testing asyncio.subprocess of Trollius with Python 2.6, I found > a race condition. If the process exits between the creation of the > subprocess transport and the creation of Process object, > transport.get_pid() fails in Trollius. It looks like it doesn't occur > in Tulip because Tulip creates less futures thanks to "yield from". > (It was easy to fix the issue in Trollius, just get the pid from the > Popen object.) > > But there is a second race condition which should also concern Tulip: > if Popen.wait() or Popen.poll() is called after the process exited, > the return code cannot be retrieved in Popen because asyncio already > called os.waitpid(). In Python 3.3, Popen.wait() uses the exit code 0 > in this case. In Python 2.7, an error is raised (ESRCH). > > Victor > -- --Guido van Rossum (python.org/~guido)
