Support for registering signal handlers

[ceedubs]

Within a Unison main method it would be helpful to have a way to listen to signals sent to the UCM process. Some common use-cases are:

• Listen to SIGINT and/or SIGTERM to gracefully shut down the application.
• Listen to SIGHUP or SIGUSR1 as an indication that config files have changed and should be reloaded.

Both of these examples would be useful in the implementation of Unison Cloud.

System.Signal is an example of a Haskell library with a basic interface for registering signal handlers. It doesn't have helper methods for some common signals like HUP, USR1 and USR2, but those can be defined in user code.

Windows support?

I don't know much about signal handling on Windows, so one question that I had was whether this would work in a Windows environment. It looks like the System.Signal package linked above claims Windows support.

Various flavors of run

There are at least 3 ways to run UCM programs that I can think of:

• run from within the ucm shell prompt (ex: run main)
• ucm run from the terminal (ex: ucm run main)
• ucm run.compiled from the terminal (ex: ucm run.compiled main.uc).

For my purposes I only really care about signal handling in the run.compiled version. But it kind of seems like the ucm run version should behave similarly. It's less clear to me whether the first example (run within the ucm shell) should do anything with the handlers; when should signals be handled by ucm vs forwarded to the underlying program?

[stew]

I'd propose adding the following builtins:

{{
  set the signal mask to allow exactly the set of signals in the Set
}}
Signal.setMask: Set Int -> {IO}()

{{
  set the current signal handler for the given signal
}}
Signal.installHandler: Int -> '{IO}() -> {IO}()

{{
  remove the given signal from the set of allowed signals
}}
Signal.block: Int -> {IO}()

{{
  add the given signal to the Set of allowed signals
}}
Signal.unblock: Int -> {IO}()

[stew]

We may want to dumb it down to just the installHandler builtin, which is all that would be strictly needed, and might make it more likely to be portable to windows and perhaps chez scheme, not sure

[ceedubs]

@stew those Ints can be Nats, right?

[stew]

they are Int's in the haskell because they are signed int's in the underlying C. The range of signals that are valid are defined by the C library headers you are linking against. They do vary from system to system, and could change. I think the valid range changed from 0-32 to 0-64 sometime as recently as the last couple of decades