hive.py is currently largely for testing the pybind stuff, so changes to it will likely
be frequent and arbitrary for now.
Added pybind for llarp::path::PathHopConfig, but not every member -- just rc and upstream routerID
Hive now uses std::queue with mutex instead of our lockless queue.
Removed some functions from Hive that will not be necessary as things are being handled from python.
a bunch of routers logging to stdout at the same time is a complete
charlie foxtrot. until we take the time to make logger not a singleton
(and probably make each router able to log to its own file rather than stdout)
just make it not log.
Note: this is very temporary, as the logs will be annoying for testing the
pybind stuff and shouldn't be necessary for debugging it
Router now has a hive pointer if LOKINET_HIVE is set.
llarp::Context has a method InjectHive to give Router the pointer.
Router has a method NotifyRouterEvent which does:
- when LOKINET_HIVE is set, passes the event to RouterHive
- else when LOKINET_DEBUG is set, prints the event at a low log level
- else NOP
This caused some unwanted behaviour:
- on initial startup we often get two publishes in quick succession
because we're publishing and building paths at the same time
- at the 10m mark we enter a publish loop every 5 seconds because we
have paths with lifetimes < 10min that was triggering this condition,
and yet those paths will never actually be included in the introset
because they are expiring in <10m.
This should ensure that we have enough shortly after startup for initial
path builds.
The spread speed here gets slightly increased to lifetime/5 (=4min)
instead of lifetime/4 (=5min) so that our "normal" number of paths is 5
with occassional momentary drops to 4, but should always keep us >= the
new minimum of 4.
Because the path spread happens over time, this shouldn't result in a
rebuild of several paths: we'll build 4 quickly, then another at +4m,
another at +8m, etc. When the initial 4 expire, we'll be dropping from
9 to 5 established but that's still above the minimum (4) so we won't
need to reconnect to several at once, and the spread builds should keep
us at 5 all the time.
So we get `v0.7.0` instead of `lokinet-0.7.0-abcdef12`; the latter is
useful for devs, but not so much for random operators (and you can
always go get the full version from the binary).
string_view was implicitly convertible to std::string, but
std::string_view is only explicitly convertible. This makes the
`operator std::string` explicit to be more compatible, and re-adds a
bunch of explicit string casts to the code where needed.
(This also fixes the build if changing the standard to c++17)
They are fairly useless under stdlibc++ because it doesn't have the
required annotations on stl mutexes and locks, so we just get tons of
useless warnings.
Pre-C++17 char_traits::compare isn't constexpr so we can't constexpr the
find/rfind methods that use it.
begin() etc, however, can be constexpr (and need to be for some of the
other constexpr methods here that use them).
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).
This was being used to get at gcc/clang's __builtin_expect, but we don't
really need that: we can just avoid the check entirely when not in debug
mode which should be even faster.
fromEnv here wasn't usefully templatized (the base template basically
couldn't be used for anything except a string anyway), so just replaced
it with the overloads we need and moved the implementations out of the
header.
Adds a TrimWhiteSpace instead of using abseil's.
Adds Catch2 tests for it, and also converts the existing str tests to
catch (which look much, much nicer than the gtest ones).
The comparison done here was really weird: by comparing lengths *before*
contents "zz" would sort before "aaa". It wasn't invalid for the
specific purpose being used here (looking for true/false values), but
would be highly broken if someone tried to use it elsewhere.
Also renamed it because it really is just a `<` implementation, not a
full cmp implementation.
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
