Closed tstenner closed 2 years ago
As Tristan said, I looked over this quite carefully (except for the Boost excision parts) and I didn't identify any problems. @tstenner , if no one else interjects (e.g., with a request for more time) before Monday then IMO you are free to merge.
shared_mutex
in the inlet connection is the last remainder of Boost.Mutex, as it first appears in the C++17 stdlib.This PR falls back to a plain mutex /
unique_lock
instead ofshared_lock
for C++11 builds and removes the rest of Boost.Mutex and its dependencies (564 files, 118626 lines).Using a
unique_lock
to protect thehost_info
gives a tiny speedup when the lock isn't held be another thread but blocks while another thread copies data from the host info. In practice, it's not noticable as accesses to thehost_info
are rare and not in a hot path; additionally the time the mutex is held in the endpoint resolution has been reduced to the absolute minimum (1f41390).Special care has been taken to ensure that no code path relies on multiple readers holding a
shared_lock
or blocks indefinitely during stream recovery (many thanks to @cboulay for going through every mutex usage individually and critical feedback!).