Summary:
Optimize the management of available hazard pointers in the domain that are not in thread caches, by adding a linked list of available hazard pointers with a lock bit packed with the pointer to the head of the list. Pop operations are done in two atomic steps: (1) set lock bit, (2) pop hazard pointers and clear lock bit. Push operations are done in one atomic step, but can proceed only when the lock bit is clear.

Microbenchmark results (in a process with 10K+ hazard pointers) show reduction in the latency of constructing destroying two 9-hazard-pointer-arrays that involve one TC hit and one TC miss/overflow from hundreds of microseconds to tens of nanoseconds.

Before:
```
1/1000 TC hit + miss & overflow                   550 ns    502 ns    468 ns
```

After:
```
TC hit + miss & overflow                           49 ns     48 ns     48 ns
```

Reviewed By: yfeldblum

Differential Revision: D31102053

fbshipit-source-id: ae923bf3b05676e7572cca35179531e947846300

Summary:
Add a microbenchmark for thread cache misses.

Add member function evict to hazptr_tc.

Add free function hazptr_tc_evict for use in testing and benchmarking only.

Remove the warning for thread cache overflow.

Add member function delete_hazard_pointers to hazptr_domain to be used only for testing and benchmarking.

## Microbenchmark Results

Results for TC hits and misses under an extreme case of 10000 in-use hazard pointers:
```
10x construct/destruct hazptr_array<9>            105 ns     97 ns     95 ns
1/1000 TC hit + miss & overflow                   550 ns    502 ns    468 ns
```

The latency for constructing/destroying a 9-hazard-pointer-array from TC hits is about 10 ns.

The latency for constructing/destroying two 9-hazard-pointer-arrays from one TC hit and one TC miss/overflow is about 500 us (i.e., 500,000 ns).

Reviewed By: yfeldblum

Differential Revision: D31102027

fbshipit-source-id: dee7333d77ebde25dcf18c6af72cc04e99788e43

Summary:
`throwCallback()` holds a read lock on the global map while unwinding the stack trace, blocking all other threads from deleting (and thus throwing) exceptions, since the deleter needs a wlock.

Switch to per-`ExceptionMeta` locking (on top of the map's locks), so we can hold the global lock only for the time to update the map, and move all unwinding, allocation, deallocation, and callbacks outside of it.

Reviewed By: luciang

Differential Revision: D31905278

fbshipit-source-id: f46228dd815bfde844165dd7aee92d6c023ff049

Summary: Fix C++20 compile

Reviewed By: ispeters

Differential Revision: D31898506

fbshipit-source-id: b7cba220dfb78d13181ae04a298e409cc883eda8

Summary: Fix CPP20 compile issues

Reviewed By: ispeters

Differential Revision: D31900132

fbshipit-source-id: 3338b84cc6aff8f317aad8a93a3e1fba5fdc6fc0

Summary:
After calling `IOBufQueue::append(IOBuf)` (both the `unique_ptr` and value overloads) the existing writable tail is lost, because the new tail buffer may not have a writable tail (in practice it's often shared or sized to fit).

This is especially a problem for zero-copy Thrift serialization, for example of a struct like
```
struct S {
  1: binary (cpp2.type = "folly::IOBuf") data;
}
```
Thrift allocates at least 16KiB for each new buffer, and writes a handful of bytes before and after the `IOBuf`, so the epilogue will take a whole new 16KiB allocation. The problem is amplified with consecutive binary fields, if they don't fit in 4KiB (`kMaxPackCopy`) and the existing writable tail, each will cost an extra 16KiB, which means a 4x memory amplification.

This diff reuses the previous writable tail buffer by appending a new `IOBuf` to the chain that references it.

Reviewed By: philippv

Differential Revision: D31882377

fbshipit-source-id: fe1d0c82f7df5528534d42b46da78f6597a9e519

Summary: Fix C++20 build issues

Reviewed By: ispeters

Differential Revision: D31848258

fbshipit-source-id: 55c7029f371f5686e62817712f9900ba4a2b4d0d

Summary:
Nifty little trick to abstract over friend classes.
See: https://awesomekling.github.io/Serenity-C++-patterns-The-Badge/.

Reviewed By: yfeldblum

Differential Revision: D31881896

fbshipit-source-id: 651eaa10336909973478c23dac1de548adb51f6f

Summary: A simple folly::RequestData implementation.

Reviewed By: praihan

Differential Revision: D31738010

fbshipit-source-id: 3d7c3394fd3daf2dbb2942fe6cdac25207e04e32

Summary:
`F14Table::prehash()` will prefetch the first cache line of the chunk, which F14 is guaranteed to need to find the item. However, more cache lines may be needed. `F14Table::prefetch()` will speculatively prefetch the next 2 cache lines of the chunk, up to the chunk size.

I chose to add this prefetching to a new function `prefetch()` instead of putting it in `prehash()` because these loads are speculative. They may end up polluting the L1 cache with useless cache lines, if the item was in the first cache line. So I think it makes most sense to be explicitly opt-in, for latency sensitive use cases that know they have cold maps.

Lastly, I disable the prefetching in `findImpl()` when using a `F14HashToken`, assuming that when it matters the caller will use `prefetch()`.

Reviewed By: shixiao

Differential Revision: D31751971

fbshipit-source-id: 62043702bb026143cf32c129ac8ba8246d4883bc

Summary: Fix C++20 build issues

Reviewed By: ispeters

Differential Revision: D31842893

fbshipit-source-id: 64a4332939fd101b99ccba6f27c7df740a346844

Summary: C++20 fixes

Reviewed By: ispeters, meyering

Differential Revision: D31832469

fbshipit-source-id: 367b9d68104ae8a6e58cc11445b0489cbe9bcf84

Differential Revision:
D31823117

Original commit changeset: 115a59d69d4c

fbshipit-source-id: 5245896f91b26977f6d8bab204a4e719c23c0900

Reviewed By: vitaut

Differential Revision: D31823117

fbshipit-source-id: 115a59d69d4c91ac35d60764ab24de175e27207c

Summary:
These boost macros have a longstanding warning problem, not fixed in VS 2019
```
folly\overload.h(72): warning C4003: not enough arguments for function-like macro invocation 'BOOST_PP_TUPLE_TO_LIST_1'
folly\overload.h(73): warning C4003: not enough arguments for function-like macro invocation 'BOOST_PP_TUPLE_TO_LIST_1'
```

Reviewed By: kosievdmerwe

Differential Revision: D25497039

fbshipit-source-id: 47e6555681f043d6d7a80cc0c963d6e326e70242

Summary:
ConstructorCallback enables the addition of callback functions to be called when a class constructor is called (D27056139 (https://github.com/facebook/folly/commit/d31902b958fc21c7bf812b0ec45c796b4bf9073c)). The ConstructorCallback object holds a static array with all installed callbacks. When a class constructor is called, the ConstructorCallback constructor traverses the array and executes each installed callback. The array is destroyed when all instances of the class are destroyed.

This diff fixes a potential concurrency issue when ConstructorCallbacks are destroyed: the callback array is destroyed while another thread is calling the class constructor and potentially looping through the callback array. We fix the issue by putting the callback array, the callback count, and the mutex into a struct and initializing a `createGlobal` object from the struct.

**Facebook:**

We describe the issue in more detail in T100230454.

Reviewed By: bschlinker

Differential Revision: D30910255

fbshipit-source-id: d345900dbadbf2e009719b6f930ab1d8aa284647

Summary:
Extending the current support for python futures <-> folly tasks interop to also support cancellation.

By adding a new version of `bridgeCoroTask` that also accepts a `folly::CancellationToken` we can give python code the ability to cancel the folly task.

Reviewed By: nanshu

Differential Revision: D31765430

fbshipit-source-id: 4277e94e296f56b998c9c583823a93ce5b9e7586

Summary: Fix C++20 build

Reviewed By: luciang

Differential Revision: D31786941

fbshipit-source-id: 153ffcee7b64f4c6dfafb786df90e909cee723b3

Summary: No thread id available built-in in emscripten, even though it has partial pthread support. Stub it out.

Reviewed By: boguscoder

Differential Revision: D31754569

fbshipit-source-id: 29113ba31cf6b65e7d5c52455fd99ee1e659c041

Summary: Since all the other lock utilities are there.

Differential Revision: D31523986

fbshipit-source-id: 22a071c50e51518b061980d7429d1a28755dbe40

Summary:
For MSVC, `ssize_t` and `std::make_signed_t<std::size_t>` are different types (even though both are 32 bit signed integer, `std::is_same` is false: https://godbolt.org/z/n4Wfbh3nM). This creates type mismatch between header and cpp file.

This diff changed to include `folly/portability/SysTypes.h` which defines `ssize_t` in a portable way.

Reviewed By: ot

Differential Revision: D31722673

fbshipit-source-id: c8968d5e0b5ac12d8d6ab4c141f791cb73d80686

Summary: Fix -Werror,-Wunused-result

Reviewed By: ispeters

Differential Revision: D31786026

fbshipit-source-id: 51af8e21a02f9d6f476d0cb79eb7c6d38f545f20

Summary: Fix C++20 build

Reviewed By: ispeters

Differential Revision: D31785835

fbshipit-source-id: ecfa717787546048c422084785b51e0f7d8eaa26

Reviewed By: Mizuchi

Differential Revision: D31745111

fbshipit-source-id: 45122594f59b13b8a2ab68e0dd565ded750e5e40

Reviewed By: zertosh

Differential Revision: D31753624

fbshipit-source-id: cebadddc83af19739a0ada00cb4bbfde0d640213

Differential Revision: D31755819

fbshipit-source-id: ad32b753efda887e1dae4a7a29749aefa8477e75

Summary: Workaround for -Werror,-Wambiguous-reversed-operator

Reviewed By: yfeldblum, mpark

Differential Revision: D31615526

fbshipit-source-id: 23f72e7b0aaea65d1e0cc294beef3b33d7aa985e

Summary: Adding QueueObserver to MeteredExecutor so that we are able to execute callbacks per enqueue and dequeue

Reviewed By: mshneer

Differential Revision: D30052794

fbshipit-source-id: eec2d55fcd02477791080a7b97cec98cb6ba9875

Summary:
Made the following changes AsyncTransport::LifecycleObserver callback
- added `connectAttempt()`, called for each observer when connect is invoked;
- changed `connect()` to `connectSuccess()`, called for each observer when connect is successful;

Reviewed By: bschlinker

Differential Revision: D29962337

fbshipit-source-id: f1d2c0e48b6d7e263466f74c97d701bb9df9b313

Summary: A typo in its name meant it was missing and that `dynamic::operator-(int)` was defined instead.

Reviewed By: ot, luciang

Differential Revision: D31726709

fbshipit-source-id: 42696c958f674de806dd56c3d89ec07dd60db961

Summary:
`retryingJitteredExponentialBackoffDur()` supports `jitter_param=0` (sanctioned in tests, and widely used to disable jitter based on a runtime parameter), but `std::normal_distribution` does not, so just special-case it.

In practice, libstdc++ already returns 0.

Reviewed By: yfeldblum

Differential Revision: D31722687

fbshipit-source-id: d81b1736379c596c4fc352b0067a4ad5788b0f8c

Summary: Make them a bit shorter with a bit less repetition. Performance-wise, trades away two direct calls for one indirect but perfectly-predictable call. And continues to optimize away in non-sanitizer builds.

Reviewed By: luciang

Differential Revision: D31673074

fbshipit-source-id: f6d8b66cf45a81788d1ec0c5b58241f4fc693001

Differential Revision: D31661218

fbshipit-source-id: 48535870ab2b2f86b0d4e9286365fe906110dc3e

Summary: While the baton is used to guard associated memory, if the wait times out, the associated memory is not available. There is no corresponding load-acquire, so marking the timeout may use a store-relaxed rather than a store-release.

Reviewed By: luciang

Differential Revision: D31676286

fbshipit-source-id: dd2474db1ba053337de7e84aa88e7556e630b1ce

Summary: The stripe table, which is a table of atomics, is its own data and does not guard any associated data. It must technically be atomic to avoid technical data race, but all accesses are relaxed.

Differential Revision: D31524230

fbshipit-source-id: 782b515f3845b4567ca258fd8d096f22248d60ff

Summary:
We currently bump it for clang+tsan because the clang implementation of tsan historically implements the historical pre-c++17 rule even post-c++17. But to enable libstdc++ assertions, we must also bump it for for some versions of libstdc++ when assertions are enabled.

The assertions are removed in libstdc++ trunk: https://github.com/gcc-mirror/gcc/commit/dba1ab212292839572fda60df00965e094a11252. They remain in libstdc++11.2.

Reviewed By: ot

Differential Revision: D31593055

fbshipit-source-id: a339306e86452c4bb6d9d821cd28038ab6f49767

Summary: The AsyncSocket move constructor creates a new socket and then populates member fields, such as `byteEventHelper_` and `preReceivedData_`, with the respective values from the old socket. This happens **after** any callbacks in the AsyncSocket constructor (e.g., installed with ConstructorCallback). These callbacks may need the updated values. This diffs offers the possibility to populate new socket member variables early, by adding them to the initializer list of the AsyncSocket constructor used in the move constructor.

Reviewed By: bschlinker

Differential Revision: D31318333

fbshipit-source-id: 731d24ab4c7525e6f28c3aea4d04c9c5e98409ea

Summary:
Spinlocks in user space are generally a bad idea due to tendency to
burn CPU in outlier events. Replace it with SharedMutex instead. The common
case cost could go up a bit should be better overall.

Reviewed By: yfeldblum

Differential Revision: D31654923

fbshipit-source-id: 77d249293458cd740904f777e00be1bd6834b62f

Summary: Added another line to the rsys sample app's `main.cpp`, which forced me to enable sockets and fix errors in order to get it compile and link.

Reviewed By: usikder

Differential Revision: D30192527

fbshipit-source-id: 10eb9714900ca7f7a48c11b5d8308558ca5e8208

Summary:
`folly/io/async:async_base` is not fully migrated to XROS, mitigate futures implementation for now:
* Craft out `fibers::Baton` and `IO pool` dependencies from futures.
* Add futures to CI targets.
* Add build time test to ensure `folly::Future<Unit>` symbols are generated.

This closely follows mitigation in `AROS` branch:
https://www.internalfb.com/code/aros/[a0c19baba13b]/xros/third-party/folly/folly/futures/Future.h

(any suggestions on how to properly proceed with such change are greatly appreciated!)

Reviewed By: egorich239

Differential Revision: D31497625

fbshipit-source-id: c0b2406496ca3c4f69ddadd61dbd1d75f309e8a1