Howard Hinnart's date.h is the library that was accepted as C++20
date/calendar support, so this is essentially a backport of C++20 date
time support.
(It does support timezone support, but requires more of the library and
that seems like overkill for what we need; this just prints UTC
timestamps instead, which need only a header-only include).
These aren't needed: CMake already knows how to follow #includes and
rebuild when headers change as long as the headers are included
*somewhere*. The extra .cpp files here just require building a bunch of
.cpp files with just header content that we just end up throw away
during linking (since the same things will also be compiled in whatever
other compilation units include the same headers).
- util::Mutex is now a std::shared_timed_mutex, which is capable of
exclusive and shared locks.
- util::Lock is still present as a std::lock_guard<util::Mutex>.
- the locking annotations are preserved, but updated to the latest
supported by clang rather than using abseil's older/deprecated ones.
- ACQUIRE_LOCK macro is gone since we don't pass mutexes by pointer into
locks anymore (WTF abseil).
- ReleasableLock is gone. Instead there are now some llarp::util helper
methods to obtain unique and/or shared locks:
- `auto lock = util::unique_lock(mutex);` gets an RAII-but-also
unlockable object (std::unique_lock<T>, with T inferred from
`mutex`).
- `auto lock = util::shared_lock(mutex);` gets an RAII shared (i.e.
"reader") lock of the mutex.
- `auto lock = util::unique_locks(mutex1, mutex2, mutex3);` can be
used to atomically lock multiple mutexes at once (returning a
tuple of the locks).
This are templated on the mutex which makes them a bit more flexible
than using a concrete type: they can be used for any type of lockable
mutex, not only util::Mutex. (Some of the code here uses them for
getting locks around a std::mutex). Until C++17, using the RAII types
is painfully verbose:
```C++
// pre-C++17 - needing to figure out the mutex type here is annoying:
std::unique_lock<util::Mutex> lock(mutex);
// pre-C++17 and even more verbose (but at least the type isn't needed):
std::unique_lock<decltype(mutex)> lock(mutex);
// our compromise:
auto lock = util::unique_lock(mutex);
// C++17:
std::unique_lock lock(mutex);
```
All of these functions will also warn (under gcc or clang) if you
discard the return value. You can also do fancy things like
`auto l = util::unique_lock(mutex, std::adopt_lock)` (which lets a
lock take over an already-locked mutex).
- metrics code is gone, which also removes a big pile of code that was
only used by metrics:
- llarp::util::Scheduler
- llarp:🧵:TimerQueue
- llarp::util::Stopwatch
Step 1 of removing abseil from lokinet.
For the most part this is a drop-in replacement, but there are also a
few changes here to the JSONRPC layer that were needed to work around
current gcc 10 dev snapshot:
- JSONRPC returns a json now instead of an optional<json>. It doesn't
make any sense to have a json rpc call that just closes the connection
with returning anything. Invoked functions can return a null (default
constructed) result now if they don't have anything to return (such a
null value won't be added as "result").
Our current abseil won't build with gcc 10 (its `optional`
implementation appears broken), and spews warnings under slightly older
compilers; updating to the latest stable 2019 branch fixes both issues.
This rewrites the version info using lokid's approach of compiling it
into a .cpp file that gets generated as part of the build (*not* during
the configure stage).
Among other things, this means that changing the version no longer
invalidates ccache or cmake dependencies, and because it depends on
`.git/index` git commits will cause the version to be regenerated,
making the commit tag more reliable (currently if you rebuild without
running cmake your git commit tag doesn't update).
Success case:
- the path endpoint creates and sends a LR_StatusMessage upon
successful path creation
Failure case:
- an intermediate hop creates and sends a LR_StatusMessage upon
failure to forward the path to the next hop for any reason
Both cases:
- transit hops receive LR_StatusMessages and add a frame
to them reflecting their "status" with respect to that path
- the path creator receives LR_StatusMessages and decrypts/parses
the LR_StatusRecord frames from the path hops. If all is good,
the Path does as it would when receiving a PathConfirmMessage.
If not, the Path marks the new path as failed.
LR_StatusMessage is now used/sent in place of PathConfirmMessage
