refactor(stopFlag): completly remove stopFlag for context #440
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
CodeLieutenant
force-pushed
the
feat/remove-stopflag
branch
from
16dd84c to
3e5702d
Compare
In process of removing the `stopFlag` from gemini's codebase, first step is to migrate the `Value Generators` for patitions. Using context with generators make a lot more sense then the custom built, `stopFlag`. `context` is built-in package in Go, and this is it's usecase - cancelation propagation to background task. Signed-off-by: Dusan Malusev <[email protected]>
Signed-off-by: Dusan Malusev <[email protected]>
In process of removing the `stopFlag` from gemini's codebase, first step is to migrate the `Value Generators` for patitions. Using context with generators make a lot more sense then the custom built, `stopFlag`. `context` is built-in package in Go, and this is it's usecase - cancelation propagation to background task. Signed-off-by: Dusan Malusev <[email protected]>
Signed-off-by: Dusan Malusev <[email protected]>
`context` is Go package used mainly to signal cancelation. `stopFlag` package inside of gemini was used the same way. It was just adding overhead and maintainability issues in the long run, as it was only a wrapper for `context.Context` and all at once calling the `cancel` funcs at the end of the program. This removal makes code easier to follow for everybody working on it. `context` package is well known in Go community and can serve many purposes beyond just canceling the background workers (`jobs` in gemini terminology). Hard kill in gemini was used to signal the immadiet stoppage for gemini, without pritting the results, and soft on the contrary could be triggers in a few ways: - gemini validation failed - gemini mutation failed - SIG(INT,TERM) was sent There is no reason to have HARD kill in the application, if we need hard kill, SIGKILL can be sent and everything would be stopped, there will be no need to the the cleanup as kernel will ensure that happens. `context.Context` works as a soft kill, and if something happens bad in gemini (validation fails or mutation fail) `globalStatus.HasError()` would stop all other `goroutines` from continuing if `failFast` CLI flag is passed, so the set of `softKill` is not needed. Signed-off-by: Dusan Malusev <[email protected]>
CodeLieutenant
force-pushed
the
feat/remove-stopflag
branch
from
3e5702d to
5f374f2
Compare
|
@CodeLieutenant what's the haste to get this merged ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
contextis Go package used mainly to signal cancelation.stopFlagpackage inside of gemini was used the same way.It was just adding overhead and maintainability issues in the long
run, as it was only a wrapper for
context.Contextand all at oncecalling the
cancelfuncs at the end of the program. This removalmakes code easier to follow for everybody working on it.
contextpackage is well known in Go community and can serve many purposes
beyond just canceling the background workers (
jobsin geminiterminology).
Hard kill in gemini was used to signal the immadiet stoppage
for gemini, without pritting the results, and soft on the contrary
could be triggers in a few ways:
There is no reason to have HARD kill in the application, if we need hard
kill, SIGKILL can be sent and everything would be stopped, there will be
no need to the the cleanup as kernel will ensure that happens.
context.Contextworks as a soft kill, and if something happens badin gemini (validation fails or mutation fail)
globalStatus.HasError()would stop all other
goroutinesfrom continuing iffailFastCLI flagis passed, so the set of
softKillis not needed.