[issue1606] Doc: subprocess wait() may lead to dead lock

Gregory P. Smith [EMAIL PROTECTED] added the comment: See the documentation update in trunk r65469. It adds warnings about both common pipe related pitfalls discussed in this bug. -- resolution: accepted - fixed status: open - closed ___ Python

[issue1606] Doc: subprocess wait() may lead to dead lock

Gregory P. Smith [EMAIL PROTECTED] added the comment: i'll come up with something for the documentation on this. -- assignee: - gregory.p.smith nosy: +gregory.p.smith resolution: - accepted type: - behavior ___ Python tracker [EMAIL PROTECTED]

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: Why not simply reverse the wait() and read() calls? I don't think it is sufficient if the user uses more than one pipe. The subprocess.communicate() and _communicate() methods are using threads (Windows) or select (Unix) when multiple pipes for stdin,

[issue1606] Doc: subprocess wait() may lead to dead lock

Christian Heimes added the comment: Guido van Rossum wrote: That is done precisely to *avoid* blocking. I believe the only reason your example blocks is because you wait before reading -- you should do it the other way around, do all I/O first and *then* wait for the process to exit. I

[issue1606] Doc: subprocess wait() may lead to dead lock

Raghuram Devarakonda added the comment: Look at #1256 for similar report. A doc change was suggested there as well. -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1606 __

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: I believe so, too. The subprocess docs aren't warning about the problem. I've seen a fair share of programmers who fall for the trap - including me a few weeks ago. Yes, the docs should definitely address this. Consider yet another example p =

[issue1606] Doc: subprocess wait() may lead to dead lock

New submission from Christian Heimes: The subprocess docs need a warning that code like p = subprocess.Popen(..., stdout=STDOUT) p.wait() p.stdout.read() can block indefinitely if the program fills the stdout buffer. It needs an example how to do it right but I don't know the best way to solve

[issue1606] Doc: subprocess wait() may lead to dead lock

Guido van Rossum added the comment: Why not simply reverse the wait() and read() calls? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1606 __ ___

[issue1606] Doc: subprocess wait() may lead to dead lock

Christian Heimes added the comment: Guido van Rossum wrote: Why not simply reverse the wait() and read() calls? I don't think it is sufficient if the user uses more than one pipe. The subprocess.communicate() and _communicate() methods are using threads (Windows) or select (Unix) when multiple