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

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