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.
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
Waitevent, 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.doneChcase 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.