Cargo nightly now checks whether a cfg option exists.
We need to declare the custom
options we use
and fix those that are wrong.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This makes the public key fields private to ensure that we don't
accidentally swap them out. It also moves the construction of the
subkeys into the master key type.
Since the master/self-signing/user-signing public key types are used for
public user identities as well as for the private key type we have, and
we'd like to sign the public key types it makes sense that the types
itself aren't using an Arc.
Let's instead put the Arc inside the user identity structs.
This will allow us later on to more easily sign the public key types.
This patch removes the notion of `take` vs. `peek` from
`LinkedChunkUpdatesInner` and widens the problem to a more general
approach: `LinkedChunkUpdatesInner` must support multiple readers, not
only two (`take` was the first reader, `peek` was the second reader,
kind of).
Why do we need multiple readers? `LinkedChunkUpdates::take` is
clearly the first reader, it's part of the public API. But the private
API needs to read the updates too, without consuming them, like
`LinkedChunkUpdatesSubscriber`. `peek` was nice for that, but it's
possible to have multiple `LinkedChunkUpdatesSubscriber` at the same
time! Hence the need to widen the approach from 2 readers to many
readers.
This patch introduces a `ReaderToken` to identify readers. The last
indexes are now all stored in a `HashMap<ReaderToken, usize>`. The rest
of the modifications are the consequence of that.
The test `test_updates_take_and_peek` has been entirely rewritten to be
`test_updates_take_and_garbage_collector` where it tests 2 readers and
see how the garbage collector reacts to that.
This patch implements `LinkedChunkUpdates::subscribe` and
`LinkedChunkUpdateSubscriber`, which itself implements `Stream`.
This patch splits `LinkedChunkUpdates` into `LinkedChunkUpdatesInner`,
so that the latter can be shared with `LinkedChunkUpdatesSubscriber`.
This patch adds the `LinkedChunkUpdates::peek` method. This is
a new channel to read the updates without consuming them, like
`LinkedChunkUpdates::take` does.
The complexity is: when do we clear/drop the updates then? We don't
want to keep them in memory forever. Initially `take` was clearing
the updates, but now that we can read them with `peek` too, who's
responsible to clear them? Enter `garbage_collect`. First off,
we already need to maintain 2 index, resp. `last_taken_index` and
`last_peeked_index` so that `take` and `peek` don't return already
returned updates. They respectively know the index of the last update
that has been read. We can use this information to know which updates
must be garbage collected: that's all updates below the two index.
Tadaa. Simple. The only _drawback_ (if it can be considered as such)
is that the garbage collection happens on the next call to `take` or
`peek` (because of the borrow checker). That's not really a big deal in
practise. We could make it happens immediately when calling `take` or
`peek` but it needs more pointer arithmetic and a less straighforward
code.
Ivan Enderlin