[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 t

[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: > 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

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

[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 b

[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 stdi

[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

[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]> __ _

[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