os/exec: Should *exec.Cmd
export the waitDone channel ?
#35794
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
It's a simple test case shown above. Sorry that I could not provide a link on
play.golang.org
, because I could not decide a proper executable that implemented by theNaCl
. I tried yet failed on every single guess...What did you expect to see?
Well, I expected it exit without my hitting the Enter.
What did you see instead?
Yet actually it just can't give in that simple, it holds on until I hit the Enter.
And
So I went through all the way down and finally found out that the unexported function
os/exec.(*Cmd).stdin
which was called by theos/exec.(*Cmd).Start
found out theStdin
which was assigned by me is not an(*os.File)
type, and then appended a function ( we'll just call it mister A ) who did all theio.Copy
labor to thegoroutine
field.Then, this hard-working function A was started as a goroutine by the
os/exec.(*Cmd).Start
along with another mate ( this is mister B ) appended by theos/exec.(*Cmd).writerDescriptor
for a similar reason.With all that happened, when the
os/exec.(*Cmd).Wait()
is called, it waits for theprocess
to get done, and it then waited for the channel fielderrch
to produce all the err returned by A and B. And just at here, the A stuck as the A is doing a hard work copying bytes from theStdin
which is assigned by me to thepw
which is a newly created pipe by theos/exec.(*Cmd).stdin
, and at this moment theStdin
field hasn't yet got any bytes from the other end of the network connection while at the meantime, the process was over, thepw
was actually already closed.So when I hit the Enter, the A finally found out that the
pw
to which it was trying to write data has already closed. Then theos/exec.(*Cmd).Wait()
went on.My question is
I think the whole process does make sense that the
os/exec.(*Cmd).Wait()
should wait for the read/write to complete. And yet I want to avoid hitting the Enter. So I'm wondering what if we provide a function to get a read-only channel of the channel fieldwaitDone
or make another channel to implement this? That channel could inform the user when the process is actually executed regardless of the status of A and B.I'm available for this
If that is ok, I would be glad to submit a PR.
The text was updated successfully, but these errors were encountered: