Commit Graph

7 Commits

Author SHA1 Message Date
Jason Rhinelander
7d167d3fe4 Add return types to lambda
Without these the return type could be wrong (e.g. supposed to return a
reference but returns a value).
2020-02-22 12:17:53 -04:00
Jason Rhinelander
f84ce61d66 Removed empty cpp files
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).
2020-02-21 23:39:11 -04:00
Jason Rhinelander
fe61367a87 Vastly simplified llarp::util::memFn
There is a huge pile of unnecessary machinery here that can be solved
with a few lambdas and some member function pointer type deduction.
2020-02-21 23:24:33 -04:00
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
2020-02-21 23:22:47 -04:00
Jason Rhinelander
ac1486d0be Replace absl::optional with optional-lite
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").
2020-02-19 18:21:25 -04:00
Michael
edd0ec398f
Move thread stuff to subdirectory 2019-09-03 20:52:28 +01:00
Michael
4d8fe2a8a8
Move meta programming to subdirectory 2019-09-03 20:52:28 +01:00