Summary:
[Folly] Use `relaxed_atomic` in `ShutdownSocketSet`.

It currently uses a slab of `std::atomic` states, every operation on which uses `std::memory_order_relaxed`. Which is what `folly::relaxed_atomic` is for.

Reviewed By: ot, magedm

Differential Revision: D6290453

fbshipit-source-id: a6b4df115b0de429dd544a97fdf97c088459a6d9

Summary:
Allow a Facebook-specific vcvarsall to be used. The getdeps default of
MSVC 2017 had at least one annoying bug fixed in 2019.

Reviewed By: chadaustin

Differential Revision: D31188039

fbshipit-source-id: 1f569fe1c5f4ceb68f0ddd339e6de3c8ca07588b

Summary:
[Folly] `relaxed_atomic`, `atomic` with assumed `memory_order_relaxed`.

This is useful for values which are themselves atomics but which do not guard other non-atomic data, such as counters. In such cases, there is no required sequencing between the atomic value and other memory locations, just between concurrent accesses to the same atomic value, so relaxed operations are sufficient.

Reviewed By: ot

Differential Revision: D6206542

fbshipit-source-id: c820d7fcf189350a1feda4b012cb6a6342e32104

Summary:
`NetworkSocket::data` may not always be integral; for XROS, it is `void*` instead (as a sort of no-op). Portably handle this.

Now, treat the vector and the capacity more like a vector and capacity, using `size_t` for capacity and positions. Convert explicitly where required.

Reviewed By: Orvid

Differential Revision: D31220216

fbshipit-source-id: 47db6ed72ff9124e30dacc31c6ec0427c29b3c99

Summary:
I randomly ran into this while working on something else: ThreadPoolExecutor has a field `isWaitForAll_` which:
* is only used in its subclass, `IOThreadPoolExecutor`
* has a comment referencing evbs, which ThreadPoolExecutor doesn't have relationship to but the subclass does.

Looks like this is an artefact of some old refactoring

Reviewed By: yfeldblum

Differential Revision: D31117228

fbshipit-source-id: ea7d1753a0d75ab8911cec68f3b6fb8c1f07c569

Summary: Have OSS build pick 'fizz' from 'main' (instead of 'master')

Reviewed By: knekritz

Differential Revision: D31173527

fbshipit-source-id: a223768b8d6568a6f979683d612c2bf36e1faafb

Summary:
Fix reclamation_without_calling_cleanup test to wait for the start of asynchronous reclamation which is done on a different thread.

Fix list_protect_all_bench. The node links in the list must be immutable since the List destructor retires each node in the list, whereas nodes with mutable links automatically unlink their children and retire them if a child's last link is unlinked.

Reviewed By: yfeldblum

Differential Revision: D31101932

fbshipit-source-id: 3afa4b07cd56e07eccab9be69bfe895e4f54aee8

Summary:
Context for motivation is in
https://fb.workplace.com/groups/560979627394613/permalink/2194915787334314.
This solution is different than the one we discussed in that post. I considered
implementing a set of post-evb-loop function callbacks that all took in the
ebv loop_time, but that was a bigger change than expected since currently the
callbacks are designed to not take any variables, and modifying/adding classes
like `FunctionLoopCallback` to either take a param or not seemed like overkill.
I instead implemented the callback basically the same as setMaxLatency
exception that the duration is a single-loop duration with no exponential
smoothing or backoffs.

Differential Revision: D30916498

fbshipit-source-id: 27cc7edf919ab11d2ee75a7f722b6a48b193c445

Summary:
Make the map and the mutex leaky singletons, grouping them together.

Tweak variable names.

Avoid double work in overloads of `close`.

Reviewed By: Orvid

Differential Revision: D31065456

fbshipit-source-id: eec1474909706df3330bd3464ebeb90ad768607b

Summary:
As mentioned in D30901400 (https://github.com/facebook/folly/commit/b258ee31860b47b9196872264f6f3a331d450b1f) / OSS commit b258ee31, `folly::Subprocess::CLOSE` has implications that are rather suboptimal in real-world use.

To recap, opening a socket or file will use the lowest unused fd number, meaning that if we close stdin/stdout/stderr they can be replaced by a random file or socket. This may result in unexpected behaviour.

Reviewed By: luciang

Differential Revision: D30991108

fbshipit-source-id: 9055af84423500a1896015b5fe866ceb2cc64186

Summary:
There's no compelling reason I could uncover why someone with a const folly::LogCategory* shouldn't be able to get the propagation level, so I'm marking this method as const to allow for that.  This makes the method more consistent with all of the other get methods in the class.

For example, if one gets the category configuration map through getCategoryConfigs(), the map returned is const.

Reviewed By: yfeldblum

Differential Revision: D31066791

fbshipit-source-id: 46267ae7bb950fbd1b3c3d8b032ed2491d54e446

Summary:
Added code to skip some TFO unit tests if the kernel tcp_fastopen setting does
not support the test.

Reviewed By: mingtaoy

Differential Revision: D30937011

fbshipit-source-id: 6973897445a87744686ed568cb0c0c755faa46c3

Summary:
So that if `std::chrono::steady_clock` and `folly::chrono::coarse_steady_clock` have the same spec, time points from the two clocks are compatible.

The intention is to provide a generic interface to determine whether it is safe to interpret a time-point from one clock as a time-point from another clock.

For example, it is safe to interpret a time-point from the coarse-steady-clock as a time-point from the steady-clock, and the code marks this by giving both clocks the same spec tag, but it is not safe to interpret a time-point from the system-clock as a time-point from the steady-clock, and the code marks this by giving the two clocks different or void spec tags.

Concrete code can already do this at will. The idea is to have a generic way to do this, from within an algorithm templated over all the clock types and having no special knowledge of any clock type.

Reviewed By: simpkins

Differential Revision: D29222091

fbshipit-source-id: b9442acd08716a46e704b6d800cc1cd1d0583e25

Summary: Rather than having coarser `duration` types, the only purpose of which is signalling coarseness via a hijacked channel.

Reviewed By: simpkins

Differential Revision: D29221055

fbshipit-source-id: 025a8b94972ee77a7d4a5bd34f269c492aaf2c4e

Summary:
Returns the RequestContext object if it already exists. Uses
SingletonThreadLocal::try_get() underneath.

Reviewed By: mshneer

Differential Revision: D31046069

fbshipit-source-id: 0d1b7af870494b70d890d0b8ef9cf0b89ac67ccc

Summary: As title.  So things can return non-void from the function

Reviewed By: yfeldblum

Differential Revision: D31038691

fbshipit-source-id: c8a499ffe7e2451cc11dbfb3f7e6e49591a6444c

Summary: This diff changes the users of FanoutChannel to use the context functionality added in the previous diff. It includes a new helper class in falcon/proxy called ProxyNotificationFanoutChannel, which handles updating the current version and sending an initial NewSubscription to new subscribers with that version. This diff then changes ProxyCache, ProxyProdEntity, OverriddenBlobEntity, and OverriddenMapEntity to use ProxyNotificationFanoutChannel. (Previously, the logic in ProxyNotificationFanoutChannel was duplicated in all 4 of those classes.)

Reviewed By: aary

Differential Revision: D30889895

fbshipit-source-id: 39c9167f2bc6cc51e0b089eb5382faa498ffcb89

Summary:
One common pattern with FanoutChannel is to send to new subscribers an initial update indicating the current state of the stream. This is currently the pattern for all uses of FanoutChannel.

This pattern is currently accomplished by adding a transform to the input receiver before passing it to fanout channel. The transform updates the current state of the stream in some shared state object. That shared state object is then captured and used in the getInitialValues function passed to subscribe, in order to let new subscribers know the current state of the stream.

However, this approach can lead to a race condition. In this approach, the transform function is executed (on the transform executor) before the getInitialValues function is executed (on the FanoutChannel executor). If someone adds a new subscriber in between, getInitialValues will use the updated shared state, even though the corresponding update has not yet been sent from the output of the transform to the input of the fanout channel.

To solve this race condition, we need to ensure that new subscribers are not added between the shared state change and the fanning out of the update that led to the shared state change. To do this, this diff adds explicit support for a custom context object that can store state. The context object's update function is called on every update, allowing the shared state to be updated on each new value. The context object is also accessible to the getInitialValues function, which allows sending an update with the current state (based on the context) to new subscribers.

This enables the desired pattern without a race condition, and avoids the need for a transform.

Reviewed By: aary

Differential Revision: D30889893

fbshipit-source-id: 9a79fd5a823db1ae477b6b63170978925b791dda

Summary: This diff renames getNewReceiver/anyReceivers to subscribe/anySubscribers.

Reviewed By: aary

Differential Revision: D30889890

fbshipit-source-id: 8c3d8b1b1e930a703b5ce40e05ee129531af255e

Summary:
FanoutSender is like FanoutChannel, except that instead of listening to and fanning out values from an input receiver, it allows values to be directly pushed into the sender.

This diff changes FanoutChannel to use FanoutSender, increasing code re-use. FanoutChannel now listens to values from the input receiver, and pushes them into a FanoutSender.

Reviewed By: aary

Differential Revision: D30889891

fbshipit-source-id: 6d2ae416a5a0a895a1b1269d21f6830d45d92184

Summary: This diff changes TValue to ValueType in FanoutChannel (adhering to the folly guideline of not prefixing template parameters with T).

Reviewed By: aary

Differential Revision: D30889892

fbshipit-source-id: 2ef79620289d554c9802124426d3c4ac70a06f12

Differential Revision:
D31006847 (https://github.com/facebook/folly/commit/865e847605911ed0eab96a0170fc372d09c3de5c)

Original commit changeset: 2ce67a097c07

fbshipit-source-id: 1bd09fcd6233f8c88969856c47317fbe8c197754

Summary:
Returns the `RequestContext` object if it already exists. Uses
`SingletonThreadLocal::try_get()` underneath.

Reviewed By: yfeldblum

Differential Revision: D31006847

fbshipit-source-id: 2ce67a097c07de10b4359e3e70b820b80d885117

Summary: as in title

Reviewed By: yfeldblum

Differential Revision: D30966043

fbshipit-source-id: aebe6972edfab79d610d01edcb737bd6102aa364

Summary: Fixes an improper cast. `SingletonThreadLocal` allows a factory which returns any type, as long as that type can be reference-cast to the target type. So the new code must do a reference-cast.

Reviewed By: amlannayak

Differential Revision: D31022770

fbshipit-source-id: 0fce6008fc3e21b6082ec7dcf3c3f9019b541ae9

Summary:
We already have this functionality for Digest part.
Let's add it for Hmac.

Reviewed By: yfeldblum

Differential Revision: D30879080

fbshipit-source-id: de6feb7aa5f6fa41f9595f00c8fa4cf3087719af

Summary: Accesses the per-thread singleton if it has already been created.

Reviewed By: amlannayak

Differential Revision: D31003518

fbshipit-source-id: 959418c4bc81da2b0ab7c639cdddb6d0beaf0121

Summary:
It's possible that AsyncTransport read completed successfully in one loop, then the read coro gets a cancellation request.  In this case, prefer to return successfully with the read data.

Read cancellation need not be fatal, eg: an application may just want to interrupt a read and come back to it later.  In this case, the successfully read data could be lost.

In particular, if an EOF was lost, the application might start another read, AsyncSocket::setReadCB can assert in invalidState(ReadCallback*) because the DestructorGuard count is 0.

Reviewed By: yairgott

Differential Revision: D30964504

fbshipit-source-id: ea963e6572f2bb552899d3b1e6274bbd0bcdc265

Summary: Added the bytesAcked field in TcpInfo to represent the number of acknowledged bytes in the connection.

Reviewed By: bschlinker

Differential Revision: D30511022

fbshipit-source-id: 6056c741399a058811fee0dbd94b1722c802db13

Summary: These warnings appear when compiling with Clang modules. In this case, the `default` case should never be hit regardless of user input, so we may translate this to an unreachability hint.

Reviewed By: yfeldblum

Differential Revision: D30962081

fbshipit-source-id: 48914f79a8d40f597cb60b8d8d6d9af37ac4b655

Summary: See title.

Reviewed By: yfeldblum

Differential Revision: D30923907

fbshipit-source-id: 8cbe749fa4662a171a247c8c16f6b9bc7b587e30

fix self-assignment for OpenSSLHash::Digest, throw if context allocation fails, implement move support

Summary:
The copy assignment operator was not checking for self-assignment, which means the code was wrong when an object was being copied into itself.
Also, allocation failure in the constructor would be silently ignored and result in a segfault crash later. Throw std::runtime_error if OpenSSL context allocation fails.
Also, move constructor and move assignment operator were not implemented - they are now.

Reviewed By: yfeldblum

Differential Revision: D30879545

fbshipit-source-id: 8b06f6fe97912a03ec5480a3b7c69aebf3a7f2ca

Summary:
It's somewhat common to want to ignore `stdout` / `stderr` when spawning a child, and the current mechanism we provide to do this is `folly::Subprocess::CLOSE`.

However, this is somewhat dangerous when used without care, since any new files or sockets the child process opens will take on these low fds. From `man 2 open`,

> The file descriptor returned by a successful call will be the lowest-numbered file descriptor not currently open for the process.

Note that stdin/stdout/stderr are *not* special-cased here.

To provide a safer way to not inherit or pipe the standard fds, provide a `folly::Subprocess::DEV_NULL` option instead, which hooks up the OS-relevant null device to the fd.

`folly::Subprocess::CLOSE` will subsequently be removed.

Reviewed By: yfeldblum, luciang

Differential Revision: D30901400

fbshipit-source-id: 0b59de5da6c6a0f714233c09788fa2d0020f3823

Summary:
This change updates the CMake config to detect whether GCC's `-fcoroutines` flag is supported and enable it for the build. This is required to enable support for Folly coroutines.

Followed the instructions in GCC page about C++ coroutines to get them enabled.
https://gcc.gnu.org/wiki/cxx-coroutines

NOTE: This Wiki page used to indicate that exceptions had to be disabled to enable subroutines, but this only applied to experimental support for coroutines and it's no longer the case.

This was uncovered by the fbthrift build, which needs Folly coroutines to implement streaming. A new fbthrift test using a stream type uncovered this missing feature in our build on Fedora.

Reviewed By: yfeldblum

Differential Revision: D30026779

fbshipit-source-id: 3324c2fc52fe5db793bdaba9c81f41bfe6ef2242

Reviewed By: vitaut

Differential Revision: D30676171

fbshipit-source-id: f820b1c08750c4d844925a82d5fd710bc8a1ca5c

Summary:
Rearrange invoking asynchronous reclamation in executor.

Eliminate the LOG message about skipping asynchronous reclamation.

Reviewed By: yfeldblum

Differential Revision: D30908286

fbshipit-source-id: ee79714bf8e6253a01d04c6d2ffa81895c4133c8

Summary:
`FOLLY_HAS_STD` and `FOLLY_HAVE_STD` are now `FOLLY_HAVE_SDT`.

This typo reveals that the tests aren't run on platforms that don't have this feature enabled :/

Reviewed By: yfeldblum

Differential Revision: D30780817

fbshipit-source-id: 338fdd5e5b08f3b5347609dd783f0a75506f9e30

Reviewed By: yfeldblum

Differential Revision: D30914679

fbshipit-source-id: 79a609ed1eda97a97e6eeeb47038a1e746b75e2d

Summary:
This is useful if we want to bind to a nonlocal address or an address that doesn't exist yet.

       IP_FREEBIND (since Linux 2.4)
              If enabled, this boolean option allows binding to an IP
              address that is nonlocal or does not (yet) exist.  This
              permits listening on a socket, without requiring the
              underlying network interface or the specified dynamic IP
              address to be up at the time that the application is
              trying to bind to it.  This option is the per-socket
              equivalent of the ip_nonlocal_bind /proc interface
              described below.

Reviewed By: yfeldblum, mjoras

Differential Revision: D30903919

fbshipit-source-id: 09058cac1c14a4003525b0a7c5381ea301ca28da

Summary: Adds a new method `co_schedule()` that takes a task, schedules it on the current executor and adds it to the AsyncScope.

Reviewed By: andriigrynenko

Differential Revision: D30005811

fbshipit-source-id: 48c7aa240dc73c0b4dd54e539e620cf69c68c4fd