What are the expectations when an app receives a signal to exit?

[rmartin16]

I noticed today that toga.App.on_exit doesn't run if I press CTRL-C while the app is running; the same happens if I manually send a SIGINT or SIGTERM to the app. That wasn't what I would have expected to happen...so, it got me curious:

Are there set expectations for how an app should exit in response to non-GUI-based exit requests?

This may be even more important with the introduction of console apps.

[freakboy3742]

So - I'm not sure there's any defined expectation - if only because "CTRL-C" is "copy" on most applications, not "close/exit".

There's a distinction between passing CTRL-C at the terminal that was used to start an app, and passing CTRL-C that is running the app. In "normal" operation of a GUI app, you don't have access to terminal that started the app, so pressing CTRL-C isn't even possible.

As you've noted, this distinction doesn't exist for console apps... in that context, we will likely need to catch CTRL-C so it can be used for a system "copy" command. That's something we'll definitely need to address when we get to adding menus/commands to the Texual backend.

An explicit SIGINT/SIGTERM is another matter... I guess there's an argument to be made that those should go through "normal" exit processing. I have a mild concern about ending up with an "unclosable" app - if you mess up the definition of an on_close/on_exit handler, it's easy to end up with a app that won't close.

My initial thought is that we should set up signal handlers so that:

• SIGTERM/SIGQUIT goes through normal on_exit() handling, asking the user for confirmation.
• SIGINT triggers normal app exit handling, but doesn't call on_exit() for confirmation (think of it as "clean exit, but the user said yes to exiting")
• SIGKILL bails and exits without any error handling.

However, I'm not wedded to those interpretations. In particular, switching SIGINT and SIGTERM in those interpretations might make sense.

[rmartin16]

As you've noted, this distinction doesn't exist for console apps... in that context, we will likely need to catch CTRL-C so it can be used for a system "copy" command.

That might be reasonable; although, I feel like a lot of my experiences in the console leverages SHIFT+CTRL+C for copy....and reserves CTRL+C for interrupting the program. On macOS, though, I am endlessly frustrated with their insistent use of the SUPER key in the console...so, my experience is mostly informed from Linux.

SIGTERM/SIGQUIT goes through normal on_exit() handling, asking the user for confirmation.

I hadn't considered that the current exiting process supports deferring to the user for confirmation. Ignoring potential difficulties in determining the difference between these two scenarios, I might argue that an "in-process interrupt", that is, the user pressing CTRL+C, may benefit from user confirmation....but an "out-of-process interrupt" maybe would not. For instance, an admin is trying to gracefully shut down an app running in a screen session and no one is there to confirm the exit.

All that said, a SIGKILL cannot be caught by a process; the OS will stop the process nearly immediately without even informing the process this is happening (at least on Linux but likely elsewhere). So, this should mostly negate the concern of not being able to kill one of these apps at all....but it requires a much more blunt instrument to do so.

My understanding of the life cycle of a Toga app is still relatively naive....but I think this could warrant additional steps in the exiting process. Perhaps, in the least, (1) steps that run "no matter what" on exit and (2) steps that run for a "normal" exit.

In the case of (1), I am imagining mostly cleanup of acquired resources and saving off state. While for (2), it would be more user-interactive tasks such as prompting to save the current document kinda thing. Thinking out loud, though.

[freakboy3742]

As you've noted, this distinction doesn't exist for console apps... in that context, we will likely need to catch CTRL-C so it can be used for a system "copy" command.

That might be reasonable; although, I feel like a lot of my experiences in the console leverages SHIFT+CTRL+C for copy....and reserves CTRL+C for interrupting the program. On macOS, though, I am endlessly frustrated with their insistent use of the SUPER key in the console...so, my experience is mostly informed from Linux.

Heh - so, as a macOS user, the fact that Windows/Linux uses CTRL not CMD is immensely frustrating, as CMD-c is much easier to type (it's a minor shift in thumb position, rather than requiring a wrist twist). But, a lot of this will come down to what you're familiar with :-)

SIGTERM/SIGQUIT goes through normal on_exit() handling, asking the user for confirmation.

I hadn't considered that the current exiting process supports deferring to the user for confirmation. Ignoring potential difficulties in determining the difference between these two scenarios, I might argue that an "in-process interrupt", that is, the user pressing CTRL+C, may benefit from user confirmation....but an "out-of-process interrupt" maybe would not. For instance, an admin is trying to gracefully shut down an app running in a screen session and no one is there to confirm the exit.

I guess that makes sense. My counter would be that it's a little weird to support 2 mechanism for quitting an app - CTRL-C, plus whatever the quit menu item is (CTRL-Q or CTRL-X).

My mental image of a Toga-Texual app is closer to the "grand old days of Turbo Pascal" apps - and there, CTRL-C wouldn't close the app. It might be a "cancel whatever task the app is currently doing" binding, or a copy binding. However, if you're looking at toga-textual as more of a "souped-up CLI app", then CTRL-C makes more sense as a native "quit" binding.

My understanding of the life cycle of a Toga app is still relatively naive....but I think this could warrant additional steps in the exiting process. Perhaps, in the least, (1) steps that run "no matter what" on exit and (2) steps that run for a "normal" exit.

In the case of (1), I am imagining mostly cleanup of acquired resources and saving off state. While for (2), it would be more user-interactive tasks such as prompting to save the current document kinda thing. Thinking out loud, though.

So - the two entry points we have are the on_exit handler and exit(). on_exit is the user-defined handler that answers the question "can this app exit?". That handler might include additional cleanup logic in the case where the user says yes - that's entirely up to the user implementation. exit() is the "just exit the app" API call; it doesn't ask for permission, it just shuts down the event loop, so you'd go through the normal "end of process" cleanup and shutdown. SIGKILL is the nuclear option where the app dies immediately.

That isn't quite a simple as the mapping you've described - there's no specific hook for logic that should be invoked after app shutdown has been confirmed. However, you could get that effect by overriding exit(), or adding a __del__ implementation on the app.

[rmartin16]

Hmm....I think I may have lead us in to the weeds too much by discussing specific implementations.

Given this discussion, though, I think these are my takeaways:

• GUI app support for signals
  • Currently, Toga apps are largely "signal unaware"; that is, there is no specific support for them.
  • To that end, I think it is worth considering what the default behavior should be for different signals.
    • Of course, devs can simply install whatever signal handlers they want themselves.
  • In that same vein, I also think it's worth considering a hook that always runs at exit.
• Console app support for signals
  • Console apps also do not have specific support for signals.
  • Contrary to my comments above, CTRL+C needn't exit the app.
    • I think my original comments were more geared towards less robust console apps. If you consider vim or nano, neither exits on CTRL+C; this is also true for many of these example apps using Textual.
  • However, similar to the GUI apps, it seems reasonable for some handling to exist for signals that also allows a consistent code path to be executed at exit.

[mhsmith]

If someone is using a shell to run a non-Textual GUI app, I think the only reasonable response to Ctrl-C is immediate termination.
Only a relatively advanced user would do something like this, and for an action in the console to trigger a GUI confirmation in a different window would be both surprising and inconvenient, especially to the app's own developer.

For the other signals, if you send them manually then you probably also want immediate termination. The only automatic source I can think of is that the user is logging out or restarting the computer. However, I think all the platforms have some more explicit means of notifying these conditions, which will happen before sending the signal, and that would be worth connecting to on_exit because a GUI response is normal in this case.

So signal handling would remain outside of Toga's scope, except for the specific case of Ctrl-C in Textual. If an app wants to handle them for some app-specific reason, it can do it with the Python standard library (including in asyncio).

[rmartin16]

The only automatic source I can think of is that the user is logging out or restarting the computer. However, I think all the platforms have some more explicit means of notifying these conditions, which will happen before sending the signal, and that would be worth connecting to on_exit because a GUI response is normal in this case.

This is actually probably the better place to start this discussion from: considering actual use-cases.

However, on Linux, I'd expect the shutdown notifications to be implemented as signals; I'm just not sure there's another reliable notification system universally available. Like on Windows, where some form of WM messages should be emitted.

or an action in the console to trigger a GUI confirmation in a different window would be both surprising and inconvenient, especially to the app's own developer.

Just to re-iterate, I don't think these remote notifications should trigger the app to then prompt a user to do something; I just expect the framework to support a code path to gracefully clean up and exit in response to remote requests to exit.