This resolves issues:
- 111cf90 (`handler` is not async-signal-safe)
- c8e0300 (`libc::signal` should not be used)
- b91c6c3 (Mutex can cause signals to be missed)
See also: patch 8e05702.
The API of `radicle-signals` is the same as before, and so uses of it
don't need to be and aren't changed. The behavior is slightly different
in that:
- If the channel is full then signals will not be lost, which is an
improvement. This is achieved without blocking in the signal handler.
This is possible because of the counters approach along with the
internal receipts-processing thread of the `signals_receipts` crate.
- `install()` and `uninstall()` might block very briefly if necessary to
acquire the mutex, which is now internal to and managed by the
`signals_receipts` crate, only if there are concurrent calls to them
(which is unlikely), but such blocking is guaranteed to be bounded to
be very brief. This is done so they no longer can fail to do their
purpose, which is an improvement. They still return errors if the
handling is already installed or uninstalled, respectively, which
preserves the previous use cases.
- The new `finish()` function is introduced. This is provided in case
it's ever needed to completely clean-up the facility, by terminating
the internal receipts-processing thread, to be like it hadn't been
installed before.
- The user must ensure that the notifications channel is disconnected,
by dropping the receiver(s), when doing `uninstall()` or `finish()`.
Such dropping usually occurs naturally, and already occurs for all the
preexisting uses of `radicle_signals`. (The `signals_receipts` crate
is capable of a more robust approach, but this commit doesn't use
that, to avoid changing the preexisting uses of `radicle_signals`.)
- The `TryFrom` impl for `Signal` is of `SignalNumber` which is `c_int`,
instead of `i32`, because `c_int` (the type of signal numbers) might
not be `i32` on all platforms (POSIX only requires `c_int` to be at
least 32-bit).
The version of `radicle_signals` is incremented, to reflect those
changes and the substantially different internal implementation.
The new dependency on the `base64` crate is needed by the
`signals_receipts` crate for it to work on macOS, because its dependency
on the `sem_safe` crate uses `base64` as part of creating anonymous
semaphores on macOS (which lacks support for unnamed semaphores (in
violation of POSIX)).
Signed-off-by: Derick Eddington <kcired@pm.me>
Signed-off-by: Lorenz Leutgeb <lorenz@leutgeb.xyz>
47c785b916