-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
os: data race between Process.Wait and Kill #9382
Labels
Milestone
Comments
pmezard
pushed a commit
to pmezard/go
that referenced
this issue
May 10, 2015
Process.handle was accessed without synchronization while wait() and signal() could be called concurrently. A first solution was to add a Mutex in Process but it was probably too invasive given Process.handle is only used on Windows. This version uses atomic operations to read the handle value. There is still a race between isDone() and the value of the handle, but it only leads to slightly incorrect error codes. The caller may get a: errors.New("os: process already finished") instead of: syscall.EINVAL which sounds harmless. I did add accessors for the atomic operations since they only exist in the Windows version. Fixes golang#9382
CL https://golang.org/cl/9904 mentions this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
go version go1.4 windows/amd64
Looks like there is a data race between os.Process.Wait() and os.Process.Kill(). The documentation does not state these operations can be run concurrently, but if they cannot, can you suggest a way to implement some kind of timeout on started process? Like "kill it if it runs more than N seconds".
The following code triggers the issue:
when run with:
and triggers:
The text was updated successfully, but these errors were encountered: