-
Couldn't load subscription status.
- Fork 9
Gracefully shutdown workers on timeout or high mem threshold #151
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
base: main
Are you sure you want to change the base?
Changes from all commits
8ed7cbe
cd1fb10
fda7299
0d420f0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -17,6 +17,8 @@ using Test | |||||
| @testset "clean shutdown ($w)" begin | ||||||
| close(w) | ||||||
| @test !process_running(w.process) | ||||||
| @test w.process.termsignal == Base.SIGTERM | ||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm wondering where the "SIGTERM" comes from? Your PR description says:
but i think if it's a graceful close, the process just exits, meaning there is no signal at all.
Suggested change
? That's what i'm seeing when running the tests: |
||||||
| @test w.process.exitcode == 0 | ||||||
| @test !isopen(w.socket) | ||||||
| @test w.terminated | ||||||
| @test istaskstarted(w.messages) && istaskdone(w.messages) | ||||||
|
|
||||||
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 forgot that we never swapped this package over to use ConcurrentUtilities workers. We should probably do that and maintain that code in one place.
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.
it sure would be nice to maintain this in only one place... on the other hand i don't think it's ideal for a test framework to have dependencies (since then you can't use it to the test code that requires a different version of that same dependency), so i think if we were to maintain it in one place (rather than maintain a duplicate codebase here, that will slightly diverge over time) then we'd want ReTestItems to vendor it some other way
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.
(for vendoring it in some other way, we could include the other repo as a git submodule, or have the build script checkout the repo from a committed tag or something like that.)
but for now i agree it makes sense to keep it duplicated until we invest in a cleanup like that.