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

Summary: For consistency with the non-Try version

Reviewed By: Mizuchi

Differential Revision: D29961440

fbshipit-source-id: cf33d4779c6a889d2c6c42fa1ad6206b86d94088

Summary:
We only need as many slots as the number of L1 caches.

Also avoid allocating control blocks when the passed pointer has no managed object.

Reviewed By: philippv, luciang

Differential Revision: D29872059

fbshipit-source-id: 8c221b0523494c44a5c6828bafd26eeb00e573c4

Summary: This diff appears to work around a compiler bug in gcc10 with coroutines. GCC is not keeping alive a temporary passed to a coroutine function.

Reviewed By: nmagerko

Differential Revision: D29847926

fbshipit-source-id: 69e0fc4cece8f5d0e26647581800ad81b1e44c74

Summary:
This diff increases the number of domains that locally cache a context from
4 to 128. In effect, this stops sharing contexts between cores, and instead
causes each core to have its own context. (If a machine has fewer than 128
CPUs, the unused slots will never be initialized.)

This diff is an experimental tuning. We don't expect it to have large positive
or negative effects, but we do currently see a non-zero amount of CPU spent
contending on the underlying pool's mutex. So this is an attempt to address
that. We'll look at CPU after it has rolled out and assess the results.

Reviewed By: terrelln

Differential Revision: D29944813

fbshipit-source-id: 7b10cb9dd2c49c02fad1f680a1bea02747990796

Reviewed By: capickett

Differential Revision: D29942172

fbshipit-source-id: 98649f6bf911d2a7a2f0ac687fa51fe76e0b777c

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

Reviewed By: magedm

Differential Revision: D29938492

Pulled By: yfeldblum

fbshipit-source-id: d0fab63bdb59e714baaee2be15139f04958672d5

Summary: Remove single-use intermediate constants from SharedMutexImpl

Reviewed By: yfeldblum, ot

Differential Revision: D29934333

fbshipit-source-id: 5e4157fa1e6576f0fa9f2a2a10a32f0e1e24d7f5

Summary: The `folly::` prefix is not necessary from within folly's namespace and the `_v` is available on the folly trait even in C++14 builds when `std::is_trivially_copyable_v` from C++17 is unavailable.

Reviewed By: ot

Differential Revision: D29925029

fbshipit-source-id: 570d17c57ca68bea1c7c8b80ce59d8560b1aba2b

Summary: Right now the internal cancellation signal will be silently ignored, which hurts usability. Add mechanism for merging with external source and comment describing the pitfall.

Reviewed By: capickett

Differential Revision: D29935016

fbshipit-source-id: 9311930ff9fbfc0470fdcfb5d425f36e7f0aff06