Summary: Move `state_` and `addr_` to the initializer list of the AsyncSocket constructor. This is necessary as there may be installed callbacks for AsyncSocket (e.g., using ConstructorCallback) that need these values early.

Reviewed By: yfeldblum

Differential Revision: D31761420

fbshipit-source-id: 2790cff1413835927be8610d7117208ef39e1cd1

Summary: It was missing openssl-libs

Reviewed By: mzr

Differential Revision: D32139851

fbshipit-source-id: a60febe3c9e916d1b1c65dfe88a364f5bcfb33b0

Summary:
Distro name wasn't matching and thus no rpms being installed or used

Also improved the error message for unknown systems

Reviewed By: farnz

Differential Revision: D32139850

fbshipit-source-id: 438278094159f732f6b1de506490b89d2c9cd3f7

Summary:
## description
fix typo spelling grammar and replace to correct words

Pull Request resolved: https://github.com/facebook/folly/pull/1638

Reviewed By: yfeldblum

Differential Revision: D30577141

Pulled By: Orvid

fbshipit-source-id: 20c3f49fafcb6ca01a9419f5d71a2414dc7ea635

Summary: Implemented 8 times unrolled linear folding to cover for _mm_clmulepi64_si128 latency on Skylake

Reviewed By: terrelln

Differential Revision: D30376340

fbshipit-source-id: 7828639c135ba51048b60c621f5427c7ac1938b4

Summary: Fix exit-time destructor warning for hazptr_tc_evict.

Differential Revision: D32099949

fbshipit-source-id: f9f12143f4d06fda1122c8a8d741d6381105253f

Summary: BoundedQueue can be useful in many places. This implementation uses MPMCQueue/ProduerConsumerQueue and folly semaphore to achieve bounded queue behavior.

Reviewed By: iahs

Differential Revision: D31782931

fbshipit-source-id: 06aa12ee6e181641eb7b5acb0c6513b58e436d91

Summary:
Need to fix branch name for OSS mvfst so CI continues on.

Ran opensource/fbcode_builder/getdeps/facebook/update-all-github-actions.sh

Reviewed By: lnicco

Differential Revision: D32041656

fbshipit-source-id: f72aab91a3084814a5d3fa8643ae5f405908c313

Summary:
We should all be migrating to platform010, for the improved performance of its
generated code and for its improved diagnostics/portability.

cast PTHREAD_STACK_MIN to size_t, since with glibc-2.34, it now has type long

This avoids the following errors:

  folly/detail/MemoryIdler.cpp:140:18: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'long' [-Werror,-Wsign-compare]

Differential Revision: D32057242

fbshipit-source-id: 1fae2aec5829a837e2aecf068f6c2c061c911e95

Summary:
AsyncServerSocket works like this:
1) a socket is accepted from the fd
2) the socket is pushed into the socket queue
3) the connectionAccepted() callback is called with the socket is dequeued

Things happening before connectionAccepted() are like black box to us currently. For example the time taken for a socket to sit in the socket queue is completely unknown. Adding this AcceptInfo into the callback could allow us to pass more information to downstream for instrumenting.

This diff only pass timestamp of before the socket is being pushed into the queue.

Reviewed By: yfeldblum

Differential Revision: D31633582

fbshipit-source-id: 66072955318388c2410b48313d3d54078edce478

Summary:
Since callsites wanting an X509 from an AsyncTransportCertificate will have to
perform a dynamic cast to an OpenSSLTransportCertificiate, we might as well
abstract that away into a static helper.

This makes it potentially a bit easier to change implementation details in the
future without having to update a bunch of existing callsites (and it hides the
ugliness of the dynamic cast).

Reviewed By: yfeldblum, mingtaoy

Differential Revision: D31358948

fbshipit-source-id: 9ed2f81db4cf746a83871961895a0c1f1fb5c297

Summary: Fix CPP20 compile issues

Reviewed By: yfeldblum

Differential Revision: D32010566

fbshipit-source-id: 203a272c80a0d54ac7a65809feed146ae0ee70f8

Summary: I want to override this method in the next [diff](https://www.internalfb.com/diff/D31995497?entry_point=27), so I am making it virtual

Reviewed By: yfeldblum, jackerghan

Differential Revision: D31995385

fbshipit-source-id: 20855cfee0bcf809bdd477ff4820613180986178

Summary:
The intention of `setEgressBufferBackpressureThreshold()` is to bound memory usage, but it accounts for write size instead. The two can have very large discrepancy, because Thrift allocates large `IOBuf`s when serializing a message: the minimum allocation size is 16KiB, but in Thrift streaming the messages can be much smaller, which can lead to under-accounting by orders of magnitude.

This diff changes the definition to account for allocated bytes.

Differential Revision: D31927400

fbshipit-source-id: 1172f91648b3b21d7d4076d51ec9f569b0e0ba22

Differential Revision: D31976729

fbshipit-source-id: 617cce3a62bad6efbfaea0e7ea6d0f120ae35dcf

Summary: Fix typo

Reviewed By: yfeldblum

Differential Revision: D31949755

fbshipit-source-id: 31af70aa09a9b15a6bc9ed5567d0ab717956c886

Summary:
A lightweight replacement for folly::Promise for use with coroutines.
The main selling point is cancellation-awareness. It also has a smaller memory footprint (similar CPU cost) and can be `blockingWait`ed.

Differential Revision: D31561034

fbshipit-source-id: d803e02cfd7753ee1f532c8f696cf7fbf672938b

Summary: Enables implementing coro::Promise with a single allocation. Not intended for direct use by folly users.

Differential Revision: D31561033

fbshipit-source-id: ae9d350694c05710dcf7abd507f11795786da09d

Summary: Switch AutoTimer looging to fmt::format

Reviewed By: mpark

Differential Revision: D31980311

fbshipit-source-id: 91e819a169a16540984e503f7562f9c2d36f75db

Summary: Fix C++20 compile issues

Reviewed By: yfeldblum, mpark, ispeters

Differential Revision: D31938070

fbshipit-source-id: eed570b98685bfe5438a5d02f0417a40f495cb0f

Summary:
Make `folly::badge` and `folly::any_badge` noexcept constructible.
Cannot make constructors explicitly defaulted due to classes becoming aggregate types.
Aggregate type construction takes precedence over value constructors so we can construct them anywhere:
```
class A{
    A() = default;
};

int main() {
    A a = {};
}
```
Cannot mark them `explicit` either, since we prefer to have conversions auto-magical where possible.

Reviewed By: yfeldblum

Differential Revision: D31983342

fbshipit-source-id: ddeffc30e6332882a490afea5bf023522f96c18e

Summary:
Fixed some `folly::badge` docs to make them more precise.
Renamed `folly::badges` to `folly::any_badge`.
Made `folly::any_badge` an empty class that we can only lift into from a singular `folly::badge` that is a part of the badges allowed.

Reviewed By: yfeldblum

Differential Revision: D31905323

fbshipit-source-id: f48394dda2c2c6b46169087c4231443552e056e4

Summary: Fix C++20 compile issues

Reviewed By: ispeters

Differential Revision: D31943747

fbshipit-source-id: afafc8f2117c558401aaeb1a265b81fccaccf2a4

Summary: C++20 compile fixes

Reviewed By: ispeters

Differential Revision: D31943173

fbshipit-source-id: 7b3a7e4dfe73dd9e258b96d8733d0eda78aeafa9

Summary:
If a shared `IOBuf` is appended to `IOBufQueue` its tail is not considered writable, but we may write into it in the packing logic.

Fix that, and share the implementation between the pointer and value versions.

Reviewed By: luciang

Differential Revision: D31890708

fbshipit-source-id: 2b590cbcab7028af9421d29babb760869833bc65

Summary:
D30916498 (https://github.com/facebook/folly/commit/a2792966998262d7aa2e64b5390b56ddf8ff12f4) added functionality to call a max latency callback using the undamped loop time (instead of the exponentially smoothed loop time). However, that diff used the total loop time to decide when to call the callback instead of the busy time. This means that if the event base is idle on an epoll, meaning it is waiting for work to do, then we'll end up calling the max latency callback. This doesn't make a lot of sense since what we really care about is the event base taking longer than expected to do one iteration of work. From my reading of the damped loop time callback, it looks like it's using the busy time, so this brings the undamped version in line with the damped version.

Proxygen is currently the only consumer of the undamped max latency time: https://fburl.com/code/caheer2t, so this shouldn't change anyone else's counters.

NOTE: the busy time doesn't seem to include the time for the [before loop callbacks](https://fburl.com/code/zsntr8lv) which I think is a mistake. I can address this in a following diff if others agree that this is a mistake.

Reviewed By: jalopezsilva

Differential Revision: D31905279

fbshipit-source-id: 928add6243822a66ee7fa9cc0cbd93a0078ea0e9

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