Switch to async-std's underlying async-io and futures-lite crates for
better compatibility with smol and using fewer dependencies in general.
Doing this also does not substantially changing the code, which is a
plus.
So we don't pollute the root with this stuff.
Also including the same set of signals under it's own submodule of the
submodule, so it can be mass-imported, but not pollute with other
constants.
The `async-std` crate does not actually depend on the `futures` crate
for the types `Context`, `Poll`, `AsyncRead` (simply called `Read` in
`async-std`), `Stream`, and `StreamExt`. It instead relies on the
versions of `Context` and `Poll` from the Rust standard library, which
it re-exports, and provides its own definition of the `Read`, `Stream`,
and `StreamExt` traits. For this reason users of the
`signal-hook-async-std` crate are unlikely to depend on the `futures`
crate themselves, making this crate's dependency on `futures`
unnecessary.
This commit replaces these types with the versions from `async-std` and
removes the `futures` dependency from the `signal-hook-async-std` crate.
In another project I am working on that uses `signal-hook` and
`async-std`, this change removed the following 10 crates from my
dependency list:
- futures
- futures-executor
- futures-macro
- futures-sink
- futures-task
- futures-util
- pin-project
- pin-project-internal
- proc-macro-hack
- proc-macro-nested
Instead only borrow the instance mutable in the mentioned method.
But the adapter crates still require a SignalIterator which owns the
SignalDelivery instance. Both requirements can be met by using a generic
type in the SignalIterator struct and rely onto a BorrowMut parameter
constraint in its implementation.
This goes through the helper async crates too. Everything can now
provide different output types (though the only exfiltrator implemented
is still the SignalOnly, that preserves the original behaviour of
returning just the signal numbers).
Michal 'vorner' Vaner