Summary: `BasicDynamicTokenBucket` declares a copy constructor, but not copy assignment operator.

Differential Revision: D30258099

fbshipit-source-id: c993177e11023d13d01884e5060269c4d5813088

Summary:
Fix flaky test. Without this fix it is possible for the background asynchronous reclamation thread to be too slow in pushing p1 into the cohorts safe list before the main thread checks for p1's reclamation.

This fix lets the main thread wait for p1 to be reclaimed before checking that p2 was not reclaimed. Since p1 is considered for reclamation before p2, it is possible that this check would pass even if p2 was about to be reclaimed in error. So the test then retires p3 and waits for it to be reclaimed before checking again that p2 was not reclaimed.

Reviewed By: yfeldblum

Differential Revision: D30248673

fbshipit-source-id: 268edb299681ab4b7256dac591d8cacbb960a7cc

Reviewed By: yfeldblum

Differential Revision: D30232471

fbshipit-source-id: 1137e306fca34f687c99c7f2155a03515926da45

Summary: This is unsafe and leads to all kinds of bugs. It is unfortunately too late to ban it, but we can at least print a warning to help debugging and maybe discourage new uses.

Reviewed By: yfeldblum

Differential Revision: D29972469

fbshipit-source-id: 1534bcc69eaf8f105998d65c0a6503740924cffa

Summary:
Fix a bug in hazptr_obj_cohort handling of children of reclaimed nodes during reclamation of the safe list. When the cohort is active, the children nodes should be pushed to the domain (to be checked against hazard pointers) and not reclaimed immediately because it is possible that a child node is protected by hazard pointers.

Added test that catches the bug.

Reviewed By: yfeldblum

Differential Revision: D30170939

fbshipit-source-id: e5bfe46b6fa5d4e5ce5cef02a3934ced424138f0

Summary: We update the TcpInfo namespace to `folly` (previosuly `folly::tcpinfo`) to avoid introducing unnecessary namespaces and to make it slightly easier to refer to. We also move the structs in the `TcpInfoTypes.h` file to the `folly::detail` namespace and move `LookupOptions` to the `TcpInfo` class, following comments in D22134355 (https://github.com/facebook/folly/commit/68a78d99d10743b54d38a550b2f0ebdc5c872f76).

Reviewed By: bschlinker

Differential Revision: D30159429

fbshipit-source-id: 7260fc80c2e76b3439c539b65cc188b2e5517b24

Summary: `getTerminateCancellationToken()` is the public API that can be used to get a cancellation token that'll be cancelled when any of the registered signal (SIGTERM or SIGINT) is received.

Reviewed By: andriigrynenko

Differential Revision: D29883069

fbshipit-source-id: 4270c42316b80afb2c75f54de7e720dcb7a083ca

Summary: Allow this to be used by more utilities.

Reviewed By: DurhamG

Differential Revision: D29958512

fbshipit-source-id: b6a1a7017102a4ff4ad252246d3252903bbb793f

Summary: Even when RTTI is disabled, to avoid unused-arg warnings. Then use `FOLLY_TYPE_INFO_OF` to simplify the conditional compilation in `UniqueInstance`.

Reviewed By: praihan

Differential Revision: D30183405

fbshipit-source-id: 040d90751822dedb8faca561a89dcf35da25119b

Reviewed By: yfeldblum

Differential Revision: D30191509

fbshipit-source-id: 00e782bf381bd5cb126fd7b18ee3454c6b9d13a7

Summary: The fdAttach callback notifies all AsyncSocketLifecycleObservers attached to the socket that a file descriptor has just been associated with the socket. In AsyncSocket, the file descriptor is created when connect() is **called**, not when it succeeds. This callback lets observers know about the fd immediately; otherwise, observers would have to wait until the connect succeeds to learn about the file descriptor attached event.

Reviewed By: bschlinker

Differential Revision: D29910574

fbshipit-source-id: c452f1091c657a7d118b1e06546555aa04a34bf1

Summary: Allows us to serialized and unserialize StreamingStats.

Reviewed By: yfeldblum

Differential Revision: D30108179

fbshipit-source-id: 7a920acfa10e6c16613e9059049b8550478e81f0

Summary:
This is a follow-up on https://github.com/facebook/folly/issues/1594

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

Differential Revision: D30179861

Pulled By: yfeldblum

fbshipit-source-id: 8949cd95e089a14f0ee63b784cecebe93c473607

Summary: To match the behavior of non-erased unique_ptr

Reviewed By: yfeldblum

Differential Revision: D30160280

fbshipit-source-id: 7fc624fa973c5cc1effc1746b5bee6c835d28150

Summary:
Original diff D29248955 (https://github.com/facebook/folly/commit/6f4811eff3b7472347cc34c0ac9876ddd96287fc) had a bug that was causing a memory leak and was reverted.

This diff reapplies it but with an extra fix.

Reviewed By: yfeldblum

Differential Revision: D30082935

fbshipit-source-id: 0f119189fe631fc363dffe5c515a8bfa9a054cf6

Summary:
In order to collect backtraces of all threads consuming from the executor's
queue(s), we need to record their actual thread IDs. We can keep track of the IDs
in a list owned by the executor. Each thread in the pool will add its own
thread ID to the tracking list by calling `folly::getOSThreadID()` and is also
responsible for removing it from the list as it exits.

Reviewed By: yfeldblum, mshneer

Differential Revision: D30103988

fbshipit-source-id: c59a1c31811684974fdb238433bd4796d0bbf2c8

Summary:
The existing FanoutChannel construct takes in an input receiver, allows the creation of output receivers, and broadcasts all received values to the output receivers. It is good for the scenario where you already have an input receiver that you want to forward to multiple output receivers.

However, for the scenario for which there is no existing input receiver, it is a bit heavy weight. To use it in this scenario, you have to create a separate channel, pass its receiver as the input receiver to the FanoutChannel, and write values to the sender.

In addition to having to create a separate input channel that is otherwise unnecessary, it is not optimized for the case where there is a single output receiver. In many cases, there is typically only one output receiver. It would be ideal to have a construct that uses the same amount of memory as a simple channel, in the case where there is only one output receiver.

FanoutSender solves both of these problems. FanoutSender does not require an input channel, and instead allows one to directly write values to all output receivers. In addition, in the case where there is only one output receiver, it uses exactly the same amount of memory as a simple channel.

Reviewed By: aary

Differential Revision: D29896797

fbshipit-source-id: 18178f42364d53e84fb07424ed3e8cc0497e21e1

Summary:
In order to colect backtraces from all threads consuming from a
task queue, we need the ability to expose their correpsonding thread IDs.
Here we introduce a new interface `WorkerProvider` which can be used to
collect the thread IDs. The implementations of this interface will come
later in the stack.

Reviewed By: mshneer

Differential Revision: D30101184

fbshipit-source-id: 24aaaeeba1983e3917c0224e94fc741b66a4f6a4

Reviewed By: luciang

Differential Revision: D30115064

fbshipit-source-id: 53e29b7e3d1a9ea319e7e7f4a636a66c04d2bf24

Summary: Add a folly::ConcurrentHashMap GBD iterator and printer.

Reviewed By: yfeldblum

Differential Revision: D30118862

fbshipit-source-id: 4cda41bc36b4ffce10e133de4c377774fece1574

Summary: It's used for executor queues.

Reviewed By: amlannayak

Differential Revision: D30033262

fbshipit-source-id: 9c01e560890373a11b869a8e26ccec2c35267c3c

Summary:
Windows is always supporting SSE4_2, right? What could go wrong?
Well, we want to support UWP targeting ARM, meaning that well, we don't have SSE4.2, which causes all different sort of fun things.
One of them - boost screaming in agony about both NEON SIMD and SSE instructions available.
Fix it, by ensuring that we only ever declare that we support SSE, if we are not arm.

Reviewed By: rudybear

Differential Revision: D30095193

fbshipit-source-id: e303f90348116cd3b5ea618dc737a647d7aa2cd6

Summary:
Right align so number units are easier to compare.

```name=before
======================================================================================================
some bench                             relative  time/iter  iters/s  cpu-cycles  instructions
======================================================================================================
A                                                  33.19us   30.13K  100.61K     217.49K
B                                        93.71%    35.41us   28.24K  106.19K     224.50K
C                                                  24.37us   41.03K  71.86K      92.74K
D                                       163.37%    14.92us   67.02K  45.04K      77.66K
======================================================================================================
```

```name=after
======================================================================================================
some bench                             relative  time/iter  iters/s  cpu-cycles  instructions
======================================================================================================
A                                                  33.92us   29.48K     102.56K       217.49K
B                                        94.27%    35.99us   27.79K     113.75K       224.50K
C                                                  23.53us   42.51K      72.80K        92.73K
D                                       154.72%    15.20us   65.77K      47.21K        77.66K
======================================================================================================
````

Reviewed By: yfeldblum, ot, philippv

Differential Revision: D30081837

fbshipit-source-id: cbbfb7e381910c102eefca13475840c58a8b3361

Summary: This is causing a memory leak

Reviewed By: yfeldblum

Differential Revision: D30082875

fbshipit-source-id: 6b6ba9963cc45d71cb98b88b1db9a304cb7b7bda

Summary: migrating to tp2 version of CLI11. Will delete our local copy in next diff to keep this smaller

Reviewed By: shri-khare

Differential Revision: D29808579

fbshipit-source-id: c7b4cf40a64c9e8804f0eb6c749f36fabdbc79e1

Summary: Adding a oss manifest for CLI11 to fetch from github

Reviewed By: shri-khare

Differential Revision: D29833128

fbshipit-source-id: 39cae08f9a15b87da0fa6e26c7b9e0387a7cec50

Summary:
* Always copy or move the interrupt handler precisely once.
* Mark interrupt-handler heap classes as final to help the compiler devirtualize, even though it should already be able to.

Reviewed By: davidtgoldblatt

Differential Revision: D29974764

fbshipit-source-id: d39008fa4d1a37fb448d42063da907edc08aa328

Summary: as in the title

Reviewed By: Croohand

Differential Revision: D30041822

fbshipit-source-id: 923158fcba241f5cd2ace8f87fa12083fd22356c

Summary:
Setting the interrupt-handler races with setting the interrupt-exception. This is expected to occur on occasion and should be handled in both `setInterruptHandler` and `raise`. The latter is correct but the former has a bug when, if the race happens, a moved-from interrupt-handler is invoked. The fix is to be sure to invoke a non-moved-from handler.

For consistency, always performs precisely one copy or move of the handler and always invokes the handler as an lvalue-ref-to-non-const.

Reviewed By: iahs

Differential Revision: D29974165

fbshipit-source-id: faf083e97c042fda0622801fc94bbc6fbca910fd

Summary:
The state machine for the interrupt has a has-handler state which holds the handler pointer and a terminal state which holds nothing. When a handler has been stored and an exception is raised, the state machine exchanges the handler and transitions the state from has-handler to terminal, and then invokes the handler and decrements its refcount, possibly deleting it. A concurrent continuation of a future can load the interrupt and, if it is a handler, increment its refcount.

There is a possible race: the handler is loaded in both threads, its refcount decremented in the first thread and incremeneted in the second thread, and then the first thread observes an historical refcount of zero and deletes the handler. Fix this race by holding onto the handler until the core is destroyed.

Reviewed By: davidtgoldblatt

Differential Revision: D30017199

fbshipit-source-id: b6c474c630719ef8fd1cb88fa982045a523590dd

Reviewed By: wez

Differential Revision: D30017863

fbshipit-source-id: fb94a7c36e05d874fc3a6ce568a7b757c1863ffa

Summary: They will be used by upcoming changes.

Reviewed By: DurhamG

Differential Revision: D30005548

fbshipit-source-id: 6154069f7dfd9b3c9b1b1a7ea3552081c7d1641e

Summary:
the only usage of `remaining` here is in an assert and thus clang13
errors out on NDEBUG builds. Give it a trivial "usage" here.

Reviewed By: smeenai

Differential Revision: D29719883

fbshipit-source-id: 8141c3ee8ed1b852ea04ec03954c8fe1ac83c12b

Summary:
Renamed alpn option from requireAlpnIfClientSupports to
alpnAllowMismatch.

Reviewed By: knekritz

Differential Revision: D29968118

fbshipit-source-id: bb515efec22520e52444530a2de2b3835691c26c

Summary: fbstring: switch FOLLY_NOINLINE inline to FOLLY_NOINLINE

Reviewed By: yfeldblum, ot

Differential Revision: D29978049

fbshipit-source-id: ecacb51d58c0c8f10ce6f67ca1d51e9de60bff55

Reviewed By: yfeldblum

Differential Revision: D29979792

fbshipit-source-id: c18155884f1ac737b7b222b9804398b6bb31049e

Summary:
Mock Cpp2ConnContext so the supplied cert to the constructor is available to
Cpp2::ConnContext->getTransport()->getPeerCertificate() call. This change is needed by other changes.

Reviewed By: edenzik

Differential Revision: D29791757

fbshipit-source-id: 42b8bb6024c880b038925a3f95b855de0488033b

Reviewed By: yfeldblum, andriigrynenko

Differential Revision: D29914176

fbshipit-source-id: 981b75acec24391822ace833d4265fed0c5d0cb3

Summary: After D29680441 (https://github.com/facebook/folly/commit/832f135adede09d6e83e1f026c159d1b88249951) the Try path is as performant as the non-Try path on values for AsyncGenerator, and they're equivalent for Task.

Reviewed By: yfeldblum

Differential Revision: D29968047

fbshipit-source-id: 035355b64f94a3ef628c8f09b605c55956606bd1

Summary: The allocator instances may not be shared across DSOs that are loaded with `RTLD_LOCAL`.

Reviewed By: yfeldblum

Differential Revision: D29955690

fbshipit-source-id: 914196a072a1bb0709d772ba0cddc6319acde862