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

gateway: wrap ExecProcessServer Send calls with a mutex #3940

Merged

Conversation

matiasinsaurralde
Copy link
Contributor

According to gRPC ClientStream interface documentation it isn't safe to call SendMsg on the same stream in different goroutines, which we do in LLBBridgeServer implementation. The generated bindings don't provide a mechanism to avoid this scenario. This change wraps LLBBridgeServer implementation with a custom locking behavior.

Should fix the scenario described by @sipsma in #3832

frontend/gateway/gateway.go Outdated Show resolved Hide resolved
frontend/gateway/gateway.go Outdated Show resolved Hide resolved
frontend/gateway/gateway.go Outdated Show resolved Hide resolved
@matiasinsaurralde
Copy link
Contributor Author

@tonistiigi Thanks for the review, I've updated the code based on the suggestions, also ran tests implemented in #3832 incorporating these changes and they look good (no container does not exist errors).

According to gRPC ClientStream interface documentation it isn't safe to call
SendMsg on the same stream in different goroutines, which we do in
LLBBridgeServer implementation. The generated bindings don't provide
a mechanism to avoid this scenario. This change wraps LLBBridgeServer
implementation with a custom locking behavior:
https://pkg.go.dev/google.golang.org/grpc@v1.53.0#ClientStream.SendMsg

Signed-off-by: Matias Insaurralde <matias@insaurral.de>
@tonistiigi tonistiigi merged commit 1c17d98 into moby:master Jun 9, 2023
54 checks passed
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

Successfully merging this pull request may close these issues.

None yet

2 participants