feat: make ctrlc available to plugins

[cablehead]

Description

This PR adds a new method to EngineInterface: register_ctrlc_handler which takes a closure to run when the plugin's driving engine receives a ctrlc-signal. It also adds a mirror of the signals attribute from the main shell EngineState.

This is an example of how a plugin which makes a long poll http request can end the request on ctrlc: https://github.com/cablehead/nu_plugin_http/blob/main/src/commands/request.rs#L68-L77

To facilitate the feature, a new attribute has been added to EngineState: ctrlc_handlers. This is a Vec of closures that will be run when the engine's process receives a ctrlc signal.

When plugins are added to an engine_state during a merge_delta, the engine passes the ctrlc_handlers to the plugin's .configure_ctrlc_handler method, which gives the plugin a chance to register a handler that sends a ctrlc packet through the PluginInterface, if an instance of the plugin is currently running.

On the plugin side: EngineInterface also has a ctrlc_handlers Vec of closures. Plugin calls can use register_ctrlc_handler to register a closure that will be called in the plugin process when the PluginInput::Ctrlc command is received.

For future reference these are some alternate places that were investigated for tying the ctrlc trigger to transmitting a Ctrlc packet through the PluginInterface:

• Directly from src/signals.rs: the handler there would need a reference to the Vec<Arc>, which would require us to wrap the plugins in a Mutex, which we don't want to do.

• have PersistentPlugin.get_plugin pass down the engine's CtrlcHandlers to .get and then to .spawn (if the plugin isn't already running). Once we have CtrlcHandlers in spawn, we can register a handler to write directly to PluginInterface. We don't want to double down on passing engine_state to spawn this way though, as it's unpredictable because it would depend on whether the plugin has already been spawned or not.

• pass ctrlc_handlers to PersistentPlugin::new so it can store it on itself so it's available to spawn.

• in PersistentPlugin.spawn, create a handler that sends to a clone of the GC event loop's tx. this has the same issues with regards to how to get CtrlcHandlers to the spawn method, and is more complicated than a handler that writes directly to PluginInterface

User-Facing Changes

No breaking changes

[fdncred]

I saw the conversation with Ian about his Signals PR. Do we need to wait on some resolution to combine two approaches or should we land this like we discussed yesterday?

[cablehead]

I saw the conversation with Ian about his Signals PR. Do we need to wait on some resolution to combine two approaches or should we land this like we discussed yesterday?

Thanks for checking in @fdncred! Let's wait on merging. I just want to think the Signals piece through a bit more.

[fdncred]

sounds good. i've made it draft until you're ready. thanks for working on this!

[IanManske]

I looked over it very briefly, and nothing jumps out as needing fixing. Because the host shell and its plugins operate/run in different manners, I think it's fine if the underlying ctrl+c implementations are different (they might need to be). It would be nice though, if the interrupt interface for plugin authors mimicked that of the main shell code. But this is not strictly necessary.

[cablehead]

It would be nice though, if the interrupt interface for plugin authors mimicked that of the main shell code. But this is not strictly necessary.

Right, I'm going to update to set an AtomicBool on the plugin side when the ctrlc frame arrives. I'll make that a Signals though so it mirrors the main shell Engine.

[cablehead]

signals is now available on the EngineInterface:

nushell/crates/nu_plugin_example/src/commands/ctrlc.rs

Line 44 in acbd469

eprintln!("interrupt status: {:?}", engine.signals().interrupted());

[fdncred]

Thanks

[cablehead]

Thank you @fdncred!