-
Notifications
You must be signed in to change notification settings - Fork 5
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
[1.0.2] SHiP: Fix hang on exit #845
Changes from all commits
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 |
---|---|---|
|
@@ -380,6 +380,16 @@ void state_history_plugin_impl::plugin_shutdown() { | |
accepted_block_connection.reset(); | ||
block_start_connection.reset(); | ||
thread_pool.stop(); | ||
|
||
// This is a temporary fix until https://github.com/AntelopeIO/spring/issues/842 can be worked. | ||
// Drain the io_service of anything that could be referencing state_history_plugin | ||
if (app().executor().get_io_service().stopped()) { | ||
app().executor().get_io_service().restart(); | ||
while (app().executor().get_io_service().poll()) | ||
; | ||
// clear priority queue of anything pushed by poll(), see application_base exec() | ||
app().executor().clear(); | ||
} | ||
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. It looks like a SIGINT etc here will interrupt it. Probably fine. I wonder if there is a way to add some sort of sentinel to know that "anything that could be referencing state_history_plugin" has actually been drained, so we don't somehow get in a state where we loop forever here because something else unrelated is 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. Maybe just not do the 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. Interesting enough, the |
||
} | ||
|
||
void state_history_plugin::plugin_shutdown() { | ||
|
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.
With the connections torn down, is there any risk pumping the main thread below might apply a block that ship would then not see?
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.
Good call! It does seem like this could push a block into the controller that would be missed by SHiP.
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.
Actually, no I don't think that is possible. Everything that uses
app().executor().post
when they execute they are only pushed into the priority_queue to execute. So probably should clear that out again 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.
I wonder if we even need those connections to be manually torn down
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.
Probably not, but that can be cleaned up when we work the real solution.