Derick Eddington 47c785b916 signals: Use signals_receipts crate instead ...

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>

2025-04-16 20:09:44 +02:00

..

src

signals: Use signals_receipts crate instead

2025-04-16 20:09:44 +02:00

Cargo.toml

signals: Use signals_receipts crate instead

2025-04-16 20:09:44 +02:00