Process exit on ctrl+c instead of stopping rendering

[milesj]

@ccbrown

In my app, I override the ctrl+c signal handling so that I can do a bunch of custom cleanup.

When the signal is not overridden, and iocraft is rendering, and ctrl+c is pressed, the entire process just exists. Which is ideal.

However when the signal is overridden and ctrl+c is pressed, iocraft will simply stop rendering but the process will continue. This means that invalid data/state is constantly pushed through, and there's no way to exit the actual process (especially if there's multiple form inputs in a row).

How best to handle this? After looking at the docs, there's no way to listen to ctrl+c within components? No way to force a std::process::exit.

My only idea, which I haven't tried yet, is to create a custom component that hooks into my custom signal handling and reacts upon it. Not sure this is 100% possible with the provided hooks, but will report back.

[milesj]

Tried the container approach and it doesn't work because the component unmounts before the future can finish running: moonrepo/moon@97b81bd

[ccbrown]

Right, there's no way currently to listen for ctrl+c. If you want to exit the process after rendering is cancelled, I think the best you can do currently is something like this:

use iocraft::prelude::*;

#[derive(Default, Props)]
struct ExampleProps<'a> {
    did_quit: Option<&'a mut bool>,
}

#[component]
fn Example<'a>(mut hooks: Hooks, props: &mut ExampleProps<'a>) -> impl Into<AnyElement<'static>> {
    let mut system = hooks.use_context_mut::<SystemContext>();
    let mut should_exit = hooks.use_state(|| false);

    hooks.use_terminal_events({
        move |event| match event {
            TerminalEvent::Key(KeyEvent { code, kind, .. }) if kind != KeyEventKind::Release => {
                match code {
                    KeyCode::Char('q') => should_exit.set(true),
                    _ => {}
                }
            }
            _ => {}
        }
    });

    if should_exit.get() {
        if let Some(did_quit) = props.did_quit.as_mut() {
            **did_quit = true;
        }
        system.exit();
    }

    element! {
        Text(color: Color::Blue, content: "Hello!")
    }
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut did_quit = false;
    element! {Example(did_quit: &mut did_quit)}
        .render_loop()
        .await
        .unwrap();
    if !did_quit {
        std::process::exit(1);
    }
    Ok(())
}

I think there are several easy ways we could make this better though. Maybe we could add a way to specify that iocraft should not handle ctrl-c at all, e.g. with something to the effect of my_component.render_loop().ignore_ctrl_c().await. Then components would be able to listen for it.

[milesj]

@ccbrown Is it possible to have the ctrl+c be a variant on TerminalEvent? Or is it that situation where since the signal handler is overridden, it doesn't even make it to iocraft?

[ccbrown]

@ccbrown Is it possible to have the ctrl+c be a variant on TerminalEvent? Or is it that situation where since the signal handler is overridden, it doesn't even make it to iocraft?

I think it should be possible, but to be sure, could you provide a minimal example of how you're overriding the signal handler?

[milesj]

It's using tokio https://github.com/moonrepo/moon/blob/master/crates/process/src/signal.rs#L20

[ccbrown]

If this is representative of what you're doing, it's the other way around:

use iocraft::prelude::*;
use tokio::{
    join,
    signal::unix::{signal, SignalKind},
};

#[component]
fn Example(mut hooks: Hooks) -> impl Into<AnyElement<'static>> {
    let mut system = hooks.use_context_mut::<SystemContext>();
    let mut should_exit = hooks.use_state(|| false);

    hooks.use_terminal_events({
        move |event| match event {
            TerminalEvent::Key(KeyEvent { code, kind, .. }) if kind != KeyEventKind::Release => {
                match code {
                    KeyCode::Char('q') => should_exit.set(true),
                    _ => {}
                }
            }
            _ => {}
        }
    });

    if should_exit.get() {
        system.exit();
    }

    element! {
        Text(color: Color::Blue, content: "Hello!")
    }
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut signal_interrupt = signal(SignalKind::interrupt()).unwrap();

    join! {
        async {
            element!(Example).render_loop().await.unwrap();
            println!("exiting!");
            std::process::exit(0);
        },
        async {
            signal_interrupt.recv().await;
            println!("signal received!");
            std::process::exit(0);
        },
    };
    Ok(())
}

If iocraft has put the terminal into raw mode and is handling events, signal_interrupt never fires.

[milesj]

Yeah thought so. Seems like I will have to get really creative here.

[milesj]

Actually this is unexpected. When rendering in a loop and pressing ctrl+c, it looks like the tokio signal handler never fires, as it never reaches this point: https://github.com/moonrepo/moon/blob/master/crates/process/src/signal.rs#L35

The loop simply stops rendering, and the process continues. If I have multiple prompts, it will go to each and render loop every time I hit ctrl+c.

[ccbrown]

Actually this is unexpected. When rendering in a loop and pressing ctrl+c, it looks like the tokio signal handler never fires, as it never reaches this point: https://github.com/moonrepo/moon/blob/master/crates/process/src/signal.rs#L35

The loop simply stops rendering, and the process continues. If I have multiple prompts, it will go to each and render loop every time I hit ctrl+c.

Yeah, if the terminal is in raw mode for any reason, the signal handlers will never fire. So I think the best we can do here is provide a nicer way for components to handle ctrl+c.

[milesj]

Agreed. I can work on other stuff for the time being.

[ccbrown]

#149 adds an API for disabling iocraft's handling of ctrl-c. Before awaiting the render loop, you can invoke ignore_ctrl_c on the future to disable handling of Ctrl-C. Then your components can handle the events just like any other key.

my_element.render_loop().ignore_ctrl_c().await;

// or...

my_element.fullscreen().ignore_ctrl_c().await;

This is available in revision e178124d512100a0fc4c7611bb364c762df028b8 and will be released in 0.8.0. Let me know if that works or if you think there's anything else we might be able to do here!