The get_next_version function can only be safely called from shard 0,
but this constraint is not enforced in any way. As evidenced in the
previous commit, it is easy to accidentally call it from a non-zero
shard.
Introduce a runtime check to get_next_version which calls
on_fatal_internal_error if it detects that the function was called form
the wrong shard. This will let us detect cross-shard use issues in
runtime.
Derived from utils::tagged_integer, using different tags,
the types are incompatible with each other and require explicit
typecasting to- and from- their value type.
Signed-off-by: Benny Halevy <bhalevy@scylladb.com>
Instead of lengthy blurbs, switch to single-line, machine-readable
standardized (https://spdx.dev) license identifiers. The Linux kernel
switched long ago, so there is strong precedent.
Three cases are handled: AGPL-only, Apache-only, and dual licensed.
For the latter case, I chose (AGPL-3.0-or-later and Apache-2.0),
reasoning that our changes are extensive enough to apply our license.
The changes we applied mechanically with a script, except to
licenses/README.md.
Closes#9937
version_generator is a trivial class which keeps a global "version"
counter, starting with 0 and counting up on a single Cassandra node.
It is used by the gossip protocol to keep a version number for each
piece of state information, so a remote node which gets two pieces of
conflicting gossip can know which is the newer information.
In Cassandra, the counter is an atomic integer. In our implementation,
because there will be just a single gossiper per SMP machine, and the
gossiper will run on a single CPU, it can be a regular integer. But
this doesn't really help performance anyway (the version number changes
rarely, so performance of this code is insignifcant).
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
