"""
This utility is made to have a nice API for spawning and interrupting child processes. It is responsible for handling
the absolute insanity that happens on Windows when it comes to signals.
Read the masterpiece answer by Eryk Sun on stackoverflow to get the whole picture: https://stackoverflow.com/a/35792192

Use any signal on POSIX (primarily SIGINT or SIGTERM) and live happily ever after.
However on Windows...
The subprocess **MUST** be spawned with creationflags that include CREATE_NEW_PROCESS_GROUP or the signal must be
emitted to pid 0 indicating the group of the current process. Failing to do this can lead to undefined behaviour
and corruption of the process-list. Decision-flow:
  Is child process under the developer's control?
    yes (best option) -> Send the shutdown request to the child using custom communication like sockets.
    yes -> Use SIGBREAK to handle custom graceful shutdown. Sending a SIGINT is not reliable. (creationflags!)
  Does the child process implement a custom graceful shutdown API? (sockets, pipes, etc.)
    yes -> Use the child's custom solution.
  Does the child process handle SIGBREAK with graceful shutdown?
    yes -> Use SIGBREAK. (creationflags!)
  Does the child process handle SIGINT with graceful shutdown? (this is *very* unreliable)
    yes -> Try if SIGINT is usable, but depending on the setup choices of the child it could be disabled. Even if
           the child normally handles Ctrl+C in the console, that handler will may not be invoked if the process
           does not have its own console. This can be done by spawning the child with CREATE_NEW_CONSOLE. This means
           we can't send signals to it directly, but spawning a handler process we can attach that to the child's
           console and trigger a Ctrl+C or Ctrl+Break signal for them. (this applies to console processes, for
           windows we would need to look into the SendMessage API)
  Shutdown the child with the only option Windows wants to give us: terminate.
"""
