Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Wait() may deadlock if child buffer is not consumed #25

Open
lucab opened this issue Dec 5, 2016 · 0 comments
Open

docs: Wait() may deadlock if child buffer is not consumed #25

lucab opened this issue Dec 5, 2016 · 0 comments

Comments

@lucab
Copy link
Contributor

lucab commented Dec 5, 2016

As per subject, Wait() may run into a subtle deadlock if the child buffer is not drained. Consider the following example:

package main

import "github.com/ThomasRooney/gexpect"
import "fmt"

func main() {
        fmt.Printf("Starting...\n")
        child, err := gexpect.Spawn("bash")
        if err != nil {
                panic(err)
        }
        child.Expect("$")
        fmt.Printf("Got prompt..\n")

        len := 8000
        child.SendLine(fmt.Sprintf("for i in `seq %d`; do echo 'a'; done", len))
        child.SendLine(`exit`)

        fmt.Printf("Waiting for exit...\n")
        child.Wait()

        fmt.Printf("Done\n")
        child.Close()
}

When running this, Wait() will never return. Lowering the len value, it will correctly return.

The problem with the example is that child output should be asynchronously drained while waiting, otherwise it can block when writing to the pty and deadlock with the parent (gexpect) as shown in strace:

$ strace -f -p ${BASH_PID}
write(1, "a\n", 2
$ strace -f -p ${GOEXPECT_PID}
waitid(P_PID, ${BASH_PID},  <unfinished ...>

This seems to be an intrinsic limitation of Wait(), and should be properly documented similarly to https://pexpect.readthedocs.io/en/stable/api/pexpect.html#pexpect.spawn.wait

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant