Open electrofelix opened 4 years ago
The main reason this causes an issue is I was hoping to exercise the confirmation behaviour as a check in my code base without needing to mock out the promptui so that I could be sure a suitable error is returned and the code continued as expected if the required response was inputted by a user.
Unfortunately I hit a race similar to the above and AFAICT, there isn't any way to avoid it from the callers perspective.
Any thoughts on preferences for how best to resolve within the codebase here? Is a sync.Mutex Lock a good solution or should there be use of something like https://github.com/uber-go/atomic
Following test example run with
CGO_ENABLED=1 go test $(go list ./... | grep -v generated) -race
shows the is an issue with how the cursor accesses it's input valueoutputs lots of the following:
It appears that the update at https://github.com/manifoldco/promptui/blob/master/cursor.go#L138 and read at https://github.com/manifoldco/promptui/blob/master/cursor.go#L144 done by readline result in the input member to be accessed by two different goroutines triggering the race