Handle signals during plugin_initialize

[heifner]

Spring creates the controller in chain_plugin::plugin_initialize. If ctrl-c is pressed during chain_plugin::plugin_initialize chainbase can be left with a dirty-db flag.

• Move initialization of signal handing to appbase::initialize so that it is in affect during plugin_initialize.
• Do not cancel and restart the signal_set to remove SIGHUP from the signal set. This was technically not thread-safe before. The boost docs indicate shared objects are not thread-safe. Since we discussed before that there was no real reason to treat SIGHUP differently during startup, I just removed the cancel/restart. This makes it thread-safe and simplifies the implementation.

[greg7mdp]

I'm wondering, in chain_plugin_impl::plugin_startup(), we can do long processing like loading a snapshot I think. Can we still ^C out of it?

[heifner]

I'm wondering, in chain_plugin_impl::plugin_startup(), we can do long processing like loading a snapshot I think. Can we still ^C out of it?

Yes, the signal handling is now in affect from appbase::initialize on, including chain_plugin_impl::plugin_startup().

[spoonincode]

I suppose this comment should have SIGHUP removed because setup_signal_handling_on_ioc() doesn't handle SIGHUP now

[heifner]

Thanks. I actually updated the comment that was removed.

[spoonincode]

I don't think you can ^C out of loading a snapshot because I don't believe snapshot loading code polls is_quitting(). Instead the ^C will just be queued up to be handled after it's done

EDIT: well technically not queued up since it was already delivered to the async_wait thread

[heifner]

I don't think you can ^C out of loading a snapshot because I don't believe snapshot loading code polls is_quitting(). Instead the ^C will just be queued up to be handled after it's done

Related: AntelopeIO/spring#798 (comment)