Radish alpha
h
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
Radicle Heartwood Protocol & Stack
Radicle
Git
node: Fix "signals" thread to continue upon other signal
Merged did:key:z6Mko5mi...bgMH opened 1 year ago

Otherwise, previously, when one of the non-shutdown signals was received, that would cause the “signals” thread to finish, but then a subsequent signal that should cause shutdown would not because the thread no longer existed to do so. E.g. when SIGHUP or SIGWINCH was received first and ignored and then SIGTERM or SIGINT was received next, the program should still be shutdown, but it wouldn’t be. This is now fixed by simply looping to continue handling subsequent signals.

Logging is now done for:

  • Receiving of SIGHUP, at log level debug, because the default action for that signal would be to terminate the process but that is not done by radicle_signals. Someone sending that signal might want to debug why the process isn’t being terminated.
  • Disconnection of the signal-notifications channel, at log level warn, because, even though that should be impossible, if it somehow occurs then a warning is warranted.

Logging is not done for receiving of SIGWINCH, because the default action for that signal would be to ignore it, which is what radicle-node does.

A wildcard pattern is not used in the match arms, so that any future changes to the Signal variants will require reviewing their handling in the “signals” thread.

Signed-off-by: Derick Eddington kcired@pm.me

did:key:z6Mko5mi...bgMH opened with revision e49446f4 on base 4a497fa6 +15 -4 1 year ago

Otherwise, previously, when one of the non-shutdown signals was received, that would cause the “signals” thread to finish, but then a subsequent signal that should cause shutdown would not because the thread no longer existed to do so. E.g. when SIGHUP or SIGWINCH was received first and ignored and then SIGTERM or SIGINT was received next, the program should still be shutdown, but it wouldn’t be. This is now fixed by simply looping to continue handling subsequent signals.

Logging is now done for:

  • Receiving of SIGHUP, at log level debug, because the default action for that signal would be to terminate the process but that is not done by radicle_signals. Someone sending that signal might want to debug why the process isn’t being terminated.
  • Disconnection of the signal-notifications channel, at log level warn, because, even though that should be impossible, if it somehow occurs then a warning is warranted.

Logging is not done for receiving of SIGWINCH, because the default action for that signal would be to ignore it, which is what radicle-node does.

A wildcard pattern is not used in the match arms, so that any future changes to the Signal variants will require reviewing their handling in the “signals” thread.

Signed-off-by: Derick Eddington kcired@pm.me

did:key:z6MksFqX...wzpT pushed revision 2 71915b0d on base 123f7eb6 +15 -4 1 year ago

Rebase, logging tweaks.

did:key:z6MksFqX...wzpT merged revision 71915b0d at 6f8d75a0 1 year ago