lokinet

Commit Graph

Author	SHA1	Message	Date
Jason Rhinelander	b4440094b0	De-abseil, part 2: mutex, locks, (most) time - 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	4 years ago
Jeff Becker	495ad6d566	testnet patch	4 years ago
Jeff Becker	472cee2594	make static constant for decay interval	5 years ago
Jeff Becker	da5af879e9	typofix	5 years ago
Jeff Becker	f3e96e06b2	propagate error to client	5 years ago
Jeff Becker	a9c9fe9c24	limit client side path builds per ip	5 years ago
Jeff Becker	0f4c531d06	fix path resource leak	5 years ago
Jeff Becker	c3858a56df	make it compile	5 years ago
Thomas Winget	9d3e7d349c	Add per-path queues, prioritize control messages over traffic	5 years ago
Jeff Becker	7ee026fa50	make path builds work again	5 years ago
Jeff Becker	327c545530	finish multithread cryptography first pass	5 years ago
jeff	14c9ef15ed	try calling stuff in logic thread from event loop	5 years ago
Jeff Becker	3c0245f8b3	Merge remote-tracking branch 'github/master' into iwp-multi-ack	5 years ago
Jeff Becker	4bf6882c8a	more async cryptography	5 years ago
Jeff Becker	12314e8d00	ensure no crash on quit	5 years ago
Jeff Becker	5cdd92e2a3	remove more locking and make it safe	5 years ago
Michael	40aabd6d92	Use the right version of clang-tidy	5 years ago
Michael	0a1620aff2	make format	5 years ago
Michael	84601fa474	Make format	5 years ago
Rick V	16096c6adb	add debug helper lib for core dump generation on all supported windows targets had an epiphany earlier i kept having problems with static linking because i merged the GNU C runtime with the SEH library instead of merging the latter with pthread	5 years ago
Thomas Winget	38fd0552d3	Adds Link-Relay Status Messages 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	5 years ago
Jeff Becker	b9bcc2b775	make threadpool consice	5 years ago
Michael	b89689fec3	Refactor path build code	5 years ago

23 Commits (39cdc9e6dd0e59a26a3ac6ce647e6d27e3c331ad)