[issue2320] Race condition in subprocess using stdin

Ross Lagerwall added the comment: Closing this as fixed since it has been fixed on 3.2 and decided not to be backported on 3.1 and 2.7. -- nosy: +rosslagerwall resolution: out of date -> fixed status: open -> closed ___ Python tracker

[issue2320] Race condition in subprocess using stdin

Gregory P. Smith added the comment: btw, I will be backporting all recent subprocess changes to http://code.google.com/p/python-subprocess32/ there have been a lot of changes recently, i was waiting for that to settle down before bring it up to current. 3.2rc1 sounds like a good time. -

[issue2320] Race condition in subprocess using stdin

Antoine Pitrou added the comment: I confirm that it works reliably under 3.2, while it hangs as reliably under 2.7 and 3.1. Since fixing involves a C extension that is too heavy to backport to bugfix branches, I suggest closing. By the way: triagers, please don't set stage to "unit test neede

[issue2320] Race condition in subprocess using stdin

Gregory P. Smith added the comment: This is likely solved in py3k 3.2 with the C _posixsubprocess.c module. The pipe creation and cloexec flag setting is all done atomically when possible, and at least with the GIL held when not. close_fds also now defaults to True. --

[issue2320] Race condition in subprocess using stdin

Changes by Terry J. Reedy : -- stage: -> unit test needed versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6 ___ Python tracker ___ ___

[issue2320] Race condition in subprocess using stdin

Gabriel Genellina added the comment: @Robert: Yes, I'd say this is the same problem as issue4749 -- nosy: +gagenellina ___ Python tracker ___

[issue2320] Race condition in subprocess using stdin

Changes by Chris Miles : -- nosy: +chrismiles ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue2320] Race condition in subprocess using stdin

Robert Cronk added the comment: Could this problem be associated with issue4749? It was found that something goes wrong when two cmd children processes are spawned from different threads, when the first exits, it is closing file handles shared with the first (or something like that) and it's

[issue2320] Race condition in subprocess using stdin

Changes by Martina Oefelein : -- nosy: +oefe ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue2320] Race condition in subprocess using stdin

Ben Creech <[EMAIL PROTECTED]> added the comment: You can trigger this bug without use of stdin=subprocess.PIPE, or for that matter any subprocess.PIPE's, although that makes it worse. (So the name for this issue may be overly specific.) I have seen this happening intermittently in our parallel

[issue2320] Race condition in subprocess using stdin

David Naylor <[EMAIL PROTECTED]> added the comment: I'm currently developing a script that makes extensive use of threads and Popen, with threads being created dynamically and each thread creating a large number of Popen processes. If I limit the thread count to 2 (main + worker) then the pr

[issue2320] Race condition in subprocess using stdin

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: lowering the priority on this back to normal as there is a workaround: use close_fds=True. I agree that this is messy, I'm not sure if we can really fix it or even if we should. Running lsof shows the /bin/cat processes on OS X all having

[issue2320] Race condition in subprocess using stdin

Adam Olsen <[EMAIL PROTECTED]> added the comment: This is messy. File descriptors from other threads are leaking into child processes, and if the write end of a pipe never gets closed in all of them the read end won't get EOF. I suspect "cat"'s stdin is getting duplicated like that, but I haven

[issue2320] Race condition in subprocess using stdin

Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +Rhamphoryncus ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue2320] Race condition in subprocess using stdin

Changes by Christian Heimes <[EMAIL PROTECTED]>: -- priority: -> critical type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-

[issue2320] Race condition in subprocess using stdin

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: This is easily reproducable on my OS X 10.4 macbookpro. However your suggested two lines with the os.pipe to lock to prevent the problem are a red herring... Locking those does not fix it. __ Tracker <[EMAIL

[issue2320] Race condition in subprocess using stdin

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> __ ___ P

[issue2320] Race condition in subprocess using stdin

Ludwig Hähne <[EMAIL PROTECTED]> added the comment: Just realized that passing 'close_fds=True' also circumvents the problem: s = subprocess.Popen(("cat"), stdin=subprocess.PIPE, close_fds=True) Should this issue be closed as it's that easy to avoid? I would still like to know what happens here

[issue2320] Race condition in subprocess using stdin

Ludwig Hähne <[EMAIL PROTECTED]> added the comment: Hi, I narrowed the problem down to the creation of the error pipe in _execute_child: >> errpipe_read, errpipe_write = os.pipe() >> self._set_cloexec_flag(errpipe_write) If I protect these two lines with a lock, I cannot reproduce the hang anym

[issue2320] Race condition in subprocess using stdin

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks for clarifying, Jeffrey! I agree the Popen should be reentrant, since it's likey to be used that way. __ Tracker <[EMAIL PROTECTED]>

[issue2320] Race condition in subprocess using stdin

Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: Ludwig isn't really proposing that subprocess.Popen be thread-safe. That would imply that you could mess with the same Popen instance concurrently from separate threads, which shouldn't be allowed. But instead, he's asking that it not be thre

[issue2320] Race condition in subprocess using stdin

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Unless noted, none of Python's stdlib guarantees that it's thread safe. So , you have to lock. -- nosy: +benjamin.peterson __ Tracker <[EMAIL PROTECTED]> _

[issue2320] Race condition in subprocess using stdin

New submission from Ludwig Hähne <[EMAIL PROTECTED]>: Pythons subprocess module has a race condition when stdin is used. The problem can be reproduced with the following script (based on the script in issue "#1731717"/"msg32210" (slightly changed to use stdin): import sys, os, threading, su