Discussing ExitReason::Aborted

[straight-shoota]

I'm wondering about the definition of ExitReason::Aborted: It's mapped to Signal::ABRT, Signal::KILL, Signal::QUIT, and the NTSTATUS valueSTATUS_FATAL_APP_EXIT.

ExitReason was introduced in #13052 with prior discussion in #12284, but the individual associations were not discussed in detail.

The name indicates a relation to the C function abort()¹ and thus Signal::ABRT and its Windows equivalent LibC::STATUS_FATAL_APP_EXIT. So that's fine.

Signal::KILL

My most concern is with Signal::KILL. It is the absolute tool to make a process terminate and it cannot be caught or ignored. That's a distinctive difference to all other signals and can be relevant for user communication. For example the compiler uses different wording to describe the exit reason of a killed process:

crystal/src/compiler/crystal/command.cr

Lines 321 to 325 in ed7dce3

	if signal.kill?
	"Program was killed"
	else
	"Program received and didn't handle signal #{signal} (#{signal.value})"
	end

The program could never handle SIGKILL, so this special-casing makes sure to avoid suggesting that it could do that.
So I think it would be useful if ExitReason could express a difference between SIGKILL and SIGABRT without having to parse signal values explicitly in user code.

Signal::QUIT

I suppose the relation to Signal::QUIT is that it can be considered as the external equivalent of abort().
Although it's also related to Signal::TERM (which maps to ExitReason::SessionEnded) because their default behaviour is identical except that Signal::QUIT usually also implies a core dump. And an application could make a difference between handling them: TERM asks very nicely for graceful termination, while QUIT may involve skipping some cleanup tasks in order to provide debugging information.

Footnotes

1. Though not Crystal's ::abort method. It causes a normal exit. ↩