Ability to immediately kill a process

[faultyserver]

A key feature of effective group supervision is the ability to forcefully kill child processes and restart them on demand. However, Crystal's fibers don't and probably won't support pre-emption. There also isn't currently a way to "kill" a running Fiber directly. Instead, the closest we can get is waiting for a fiber to yield out and then ensuring it doesn't get added back to the scheduler.

That leads us to a problem where we don't have a nice way of doing group supervision, or even complete single-process supervision (e.g., enforcing timeouts). In fact, it's arguably impossible to implement to do this without mucking around with Crystal's internals.

That said, here's one way I think we can muck around somewhat safely:

Crystal's fibers are neatly implemented using multiple callstacks. This means that switching between fibers is as simple as calling Fiber.switch_stacks, causing the program to continue execution from wherever the new fiber left off.

Looking at Fiber#resume, it seems like we could add an overload that accepts a block, then have the block immediately raise an exception. Since the stack will have already been switched, this should cause that fiber to panic and get captured by our Process wrapper.

I might be completely off-base with this idea, but I'd like to try it out.

[faultyserver]

Thinking about it more, this doesn't actually make any sense.

Fibers are explicitly cooperative, and (at least for now) only one can ever be running at a given time. With that, it's entirely impossible to pre-empt a fiber without changing the core of how fibers are scheduled/managed, which is not something I want to do.

Instead, I think there's a simpler solution that will at least hold for the short term:

In most cases, processes are not being supervised to enforce timeouts. The general use case is restarting crashed fibers or guaranteeing that something will run until successful completion. That use case is already supported with the three process modes available now.

For processes that do need to be time-limited, there can be a separate Process subclass that starts the code in a new Thread (not a Fiber). Crystal purposefully does not currently document the Thread class, but it's there and usable, so why not ¯\_(ツ)_/¯. A further extension of this could start an entirely new (OS-level) process for things like system commands, forking workers, etc.

tl;dr pre-emption of fibers doesn't make any sense in Crystal. Instead, things that need pre-empting should be done in Threads or Processes, and Honcho::Process should become an abstract class with three implementations: FiberProcess, ThreadProcess, and ProcessProcess (well, with a better name than that).

[faultyserver]

I think the solution that's in place now is fine for fiber-based processes (where Fibers are just kept from ever being run again).