fix: Catch OS agnostic interrupt signal #755
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As per docs (https://pkg.go.dev/os/signal#hdr-Windows) os.Interrupt is an OS-agnostic "signal" as opposed to syscall.SIGINT which is Unix-only. This should enable us to catch interrupts on Windows too, therefore do more graceful shutdowns and also write CPU profile.
radeksimko
force-pushed
the
b-catch-os-interrupt
branch
from
2c34bb0
to
77a39fd
Compare
dbanck
approved these changes
Jan 10, 2022
There was a problem hiding this comment.
LGTM!
I found that it's still possible to get a 0kb file when writing CPU profiles. I assume that sometimes VSCode will relaunch the process, overwriting the "valid" profile with an empty 0kb one. The safest way to avoid this is to use a timestamp in the filename.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While debugging #733 Windows users have reported that CPU profile never gets written in their environment.
This is because CPU profile only gets written upon (graceful) shutdown which we perform by catching particular interrupt/termination signals. Prior to this patch however we were only catching Unix-native signals, which Windows never sends, resulting in dirty shutdowns and never giving the opportunity for a CPU profile to be written to disk.
See also: https://pkg.go.dev/os/signal#hdr-Windows and https://stackoverflow.com/a/35683558