Map `Ctrl+C` to cancellation of the main function

[badeend]

Currently, WASI does not describe any way for a CLI guest to receive the Ctrl+C signal (SIGINT on Unix). This signal is commonly used to request graceful shutdown, giving the application some time to e.g.:

• clean up resources,
• flush buffers to disk,
• stop listening for new network requests, while letting the existing ones run to completion,
• etc..

The component model has built-in support for async cancellation, and I think that in the CLI world Ctrl+C maps neatly to cancellation of the main (run) function.

I propose we update the documentation of the run function to say something along the lines of:

If a host wishes to propagate Ctrl+C into the guest, then cancellation of the run task is the canonical way to do so.

WDYT?

---

Related: #166

[yoshuawuyts]

Conceptually I like this a fair bit! Ctrl+C is the most commonly used Unix signal, and it seems like it should unambiguously map to cancellation of the main function.

There are additional questions about how/whether we could handle other signals in wasi:cli. But I don't think we need to answer those now to support this particular behavior.

[badeend]

There are additional questions about how/whether we could handle other signals in wasi:cli.

The referenced issue above already goes into some detail on that topic with conclusions like:

(DG): Full POSIX-style signal handling would likely be a massive undertaking, involving complex security, portability, and VM implementation considerations, and probably core wasm semantics changes (outside the scope of WASI).
(NF): POSIX signals, in their full generality, are infamously tricky, footgun-y, and generally not a paragon of API design.

So, I wanted to stay as far away from this as possible. 😃 Ctrl+C / SIGINT is by far the most commonly used one, and is also one of the few signals (if not the only) that has a 1:1 counterpart on Windows. So I'd say: lets try just this one first.

[yoshuawuyts]

Oh I hadn't clicked through on the other link; that's good to know! But it sounds like we're on the same page about this!

[lann]

I'm broadly in favor of adding some kind of documentation about this. Some questions/thoughts:

• "Graceful shutdown" won't be meaningful for all guests; what (if any) default behavior should be prescribed for cancellation? (Transitively cancel subtasks? Call exit_with_code(130)?)
• Async cancellation is cooperative and could take an indeterminate amount of time. Should we say anything about this situation? It's somewhat common for systems to treat a second Ctrl+C as a less-graceful shutdown signal, for example.
• We should be careful to distinguish this as not being simply a "propagation" of SIGINT/CTRL_C_EVENT here. Async cancellation is fundamentally less powerful than signals but close enough in simple/happy-path cases to cause confusion.

[badeend]

what (if any) default behavior should be prescribed for cancellation?

For the guest to wrap up ASAP.

Transitively cancel subtasks? Call exit_with_code(130)?

Both of those are indeed examples of how the guest could implement cancellation. Ultimately, neither the host nor the spec need to care about how the guest decides to wrap up.

Async cancellation is cooperative and could take an indeterminate amount of time. Should we say anything about this situation?

SIGINT is cooperative too, so I don't think we'll be introducing any new unexpected behavior on that front. But I agree that we should document that hosts are free to kill the process on a second Ctrl+C.

Async cancellation is fundamentally less powerful than signals

In what sense exactly? Assuming we're talking only about SIGINT and not signals in its full generality, I think they're equivalent.

close enough in simple/happy-path cases to cause confusion.

What confusion do you foresee?

[lann]

Ultimately, neither the host nor the spec need to care about how the guest decides to wrap up.

This is probably true when the host is the caller but may not be true for inter-component calls.
The quickest way for a callee to wrap up would be to trap which is probably not what a component caller would want from cancellation / graceful shutdown.

close enough in simple/happy-path cases to cause confusion.

What confusion do you foresee?

I suppose this will depend on how async cancellation is expected to behave more generally, but where SIGINT's default behavior is preemptive termination, it seems like async cancellation's default behavior may be less reliable. My expectation for SIGINT is that it will either terminate immediately or it will trigger some documented graceful shutdown / cleanup process, but with component composition the cancellation behavior may not be entirely under the run implementer's control.