On 31Mar2017 06:13, eryk sun wrote:
On Thu, Mar 30, 2017 at 10:51 PM, Cameron Simpson wrote:
This suggests that .communicate uses Threads to send and to gather data
independently, and that therefore the deadlock situation may not arise.
For Unix, communicate() uses select or poll. It uses th
Cameron!!!
You are 'da man!!
Read your exaplanation.. good stuff to recheck/test and investigate
over time
In the short term, I'll implement some tests!!
thanks!
On Thu, Mar 30, 2017 at 6:51 PM, Cameron Simpson wrote:
> I wrote a long description of how .communicate can deadlock.
>
> The
On Thu, Mar 30, 2017 at 10:51 PM, Cameron Simpson wrote:
> This suggests that .communicate uses Threads to send and to gather data
> independently, and that therefore the deadlock situation may not arise.
For Unix, communicate() uses select or poll. It uses threads on
Windows. Either way it avoid
I wrote a long description of how .communicate can deadlock.
Then I read the doco more carefully and saw this:
Warning: Use communicate() rather than .stdin.write, .stdout.read
or .stderr.read to avoid deadlocks due to any of the other OS
pipe buffers filling up and blocking the child process
On 30Mar2017 13:51, bruce wrote:
Trying to understand the "correct" way to run a sys command ("curl")
and to get the potential stderr. Checking Stackoverflow (SO), implies
that I should be able to use a raw/text cmd, with "shell=true".
I strongly recommend avoiding shell=True if you can. It ha
Trying to understand the "correct" way to run a sys command ("curl")
and to get the potential stderr. Checking Stackoverflow (SO), implies
that I should be able to use a raw/text cmd, with "shell=true".
If I leave the stderr out, and just use
s=proc.communicate()
the test works...
Any pointe
