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

embeddedProcess.Wait is somewhat racy #69

Open
mh-cbon opened this issue Aug 14, 2022 · 1 comment
Open

embeddedProcess.Wait is somewhat racy #69

mh-cbon opened this issue Aug 14, 2022 · 1 comment

Comments

@mh-cbon
Copy link

mh-cbon commented Aug 14, 2022

Hi,

while looking on my problem with the interrupt signal capture I noticed that your code is slightly racy in embeddedProcess.Wait.

An embedded process can have multiple listeners on its Wait event, but the channel is wrote only once.

If multiple readers are competing to get the exit code/wait,
it is unknown as to who will enter the code := <-e.doneCh case and who will enter the <-ctx.Done(): case.

see https://github.com/cretz/bine/blob/master/process/embedded/tor-0.4.7/process.go#L69

I guess you could use atomic.StoreInt, and close the channel rather than writing it (though don't read it, it would return the zero value). Because channels are somehow locked, i guess it is not needed to use atomic.LoadInt in replacement within the Wait method, a direct access should do fine.

@cretz
Copy link
Owner

cretz commented Aug 15, 2022

An embedded process can have multiple listeners on its Wait event, but the channel is wrote only once.

Ah yes, it wasn't really written for multiple waiters. I haven't worked on this project in a while, but would welcome a PR to support multiple waiters.

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

2 participants