-
-
Couldn't load subscription status.
- Fork 83
Add flag to register shutdown hooks for os.call and os.spawn APIs, overhaul destroy APIs
#324
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
Conversation
os.call and os.spawn APIsos.call and os.spawn APIs, overhaul destroy APIs
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 think we should rename shutdownHook to something like exitWithJvm or stopWithJvm. We don't really support any custom shtudown hook. We just use the shutdown hook mecahnism internally to stop the process when the JVM is stopped.
|
Ended up going with |
| check: Boolean = true, | ||
| propagateEnv: Boolean = true): os.CommandResult | ||
| propagateEnv: Boolean = true, | ||
| shutdownGracePeriod: Long = 100, |
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.
What's the time unit used for shutdownGracePeriod? Should we name it shutdownGracePeriodMsec?
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'll probably leave it as is, the scaladoc says it's in milliseconds so that should be enough
| destroyOnExit = destroyOnExit | ||
| ) | ||
| } | ||
| def apply( |
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.
Is this only provided for bin-compat? Shouldn't we deprecate it therefore?
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've had issues with @deprecated things being accidentally resolved here before, but will add a comment like the other forwarders
| destroyOnExit = destroyOnExit | ||
| ) | ||
| } | ||
| def apply( |
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.
Looks like this one is only for bin-compat, so we should deprecate it for removal.
This might have been the cause of a lot of flakiness that seems to have gone away with #4254, as the server exiting caused the `runBackground` calls to exit causing the http servers to exit and fail to pick up requests. Might have been caused by com-lihaoyi/os-lib#324 which made `destroyOnExit` the default for spawned subprocesses. This PR explicitly disables `destroyOnExit` for the subprocesses where `background = true` Covered by a new `integration.invalidation` test that runs under both `server` and `fork`, that previously failed when run under `fork`
Backports the functionality from Mill to allow us to register shutdown hooks such that when the parent process terminates the subprocesses are shut down as well. This allows the same logic to be used consistently across all
.calland.spawninvocationsConsolidate
SubProcess#destroyandSubProcess#destroyForciblyinto a singleSubProcess#destroymethod which takes some default parameters, allowing the user to chooseasync = trueor configure theshutdownGracePeriod: Long.The default behavior of
SubProcess#destroyhas changed to block on the subprocess actually exiting, which I think is more intuitive. The old behavior is available underdestroy(async = true)Best reviewed with
Hide whitespace. Added some simple unit tests to assert the new functionality, existing unit tests should assert on existing workflows