-
Notifications
You must be signed in to change notification settings - Fork 13
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
gracefully stop gRPC servers #401
Conversation
84909c1
to
fccc467
Compare
dc946ec
to
a002a51
Compare
* remove returning error on multiple call to Serve(), callers never should do that. * remove TestServerServeAlreadyListening test.
a002a51
to
255c268
Compare
go startServer(tcpServer) | ||
go startServer(unixServer) | ||
|
||
closing := make(chan struct{}, 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand how this is useful.
Why not doing something like
defer tcpService.Close()
defer unixServer.Close()
instead of having to create this chan that we pass as a parameters of the closeServer
we could close the server directly and not in some goroutines. I might be missing something here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes actually, that channel is needed. Close() will stop accepting incoming gRPC requests and gracefully wait current ones to end. so Close() will block until all accepted gRPC requests are done. We should only exit the program after both Close() calls has returned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and the reason why we use a goroutine and a chan is to close both server concurrently and don't force one to wait until another one closes.
related with #354 (comment)