Summary: Include the xr_socket compatibility header in multiple places in folly (net_net_ops, network_address etc.) to have these parts of folly build-able over XROS

Reviewed By: yfeldblum, luciang

Differential Revision: D31057430

fbshipit-source-id: 2aceaa1c1c50da2b1a6a1aa9d401df050d68cef1

Reviewed By: iahs

Differential Revision: D31183931

fbshipit-source-id: e97fcc99bbe6271def731916321eaf081d82d942

Summary:
1. sockaddr, sockaddr_in and sockaddr_in6 are all the same at XROS, so we should have only one version of setFromSockaddr() when running over XROS
2. Since AF_UNIX is not really a supported address family on XROS, add a cast to (int) when checking the family. This will suppress a compilation warning

Reviewed By: yfeldblum

Differential Revision: D31057427

fbshipit-source-id: ef5af0aed6800c9beadfbb217795416afab9e08c

Reviewed By: vitaut

Differential Revision: D31345855

fbshipit-source-id: ee4d9e29e3ca933a5e1f1f574c571c315e43ed36

Summary: TSIA

Reviewed By: xavierd

Differential Revision: D30825961

fbshipit-source-id: e920e4e30289fbdcea4cd6d52e6f4d2dfbd3409d

Summary: - Repo has a main branch now and not master

Reviewed By: xiangxu1121

Differential Revision: D31313971

fbshipit-source-id: 70d151e8a8632e296f25baf07ff9ac8348da7497

Reviewed By: yfeldblum

Differential Revision: D31256615

fbshipit-source-id: 0e1e5234b48a7bfeacc3f0f9c7cf394480ceee86

Summary: Add range-v3 as openr dependency

Reviewed By: xiangxu1121

Differential Revision: D31316169

fbshipit-source-id: da47159c4e4d34080baca2522f9331e988f27797

Summary: Hermes still appears to be on an older C++ standard, so std::optional isn't available and template args need to be explicitly specified.

Reviewed By: yfeldblum

Differential Revision: D31156728

fbshipit-source-id: e449192054722d9d8384e43987204516209c24ba

Summary: New method to return the cumulative CPU time consumed by the pool. Requires support for per-thread CPU clocks.

Reviewed By: yfeldblum, iahs

Differential Revision: D30685002

fbshipit-source-id: ac103e581585832bcda245e8f034bbc71489c831

Summary:
Aligns `collectAll` and `collectAny` behaviour and simplifies the logic for propagating child exceptions on cancellation.

Prior to this change, we were conditionally setting `firstException` dependent on whether cancellation was requested or not. Additionally, `collectAny` was unconditionally returning `co_cancelled` even if all the child tasks completed successfully.

Now, the behaviour is consistent between general errors and cancellation: If any child task completes in error (including folly::OperationCancelled), then the parent `collectAll`/`collectAny` will propagate that failure. Otherwise, if no child fails, then `collectAll`/`collectAny` will propagate that success.

(Note: this ignores all push blocking failures!)

Reviewed By: iahs

Differential Revision: D31266586

fbshipit-source-id: b6eba6ab2a0a3634b112318b1810819d7916acdb

Summary: Adding sha512/blake2b evp wrappers for digest/hmac.

Reviewed By: yfeldblum

Differential Revision: D31220261

fbshipit-source-id: af190fef5d269dda6e7fed549641a6cffb3ce08d

Summary: Spellcheck everything in the root and docs directory.

Reviewed By: yfeldblum

Differential Revision: D31228715

fbshipit-source-id: 3c5ace5d8879fbca17ebacf4fb6edee5e28a1b42

Summary: Basically it needs a nice constructor and `operator bool`.

Reviewed By: iahs

Differential Revision: D31188190

fbshipit-source-id: ec64d944674b0879e045aa92df95c592f66c3be4

Reviewed By: iahs

Differential Revision: D31266293

fbshipit-source-id: 99edca2496fd3764906e1c8483ff7cb1d3af0721

Summary:
D22214468 added a non-const copy constructor override. This does not compile on all platforms.

The reasoning in D22214468 pertains to overload resolution for copies. The specifics for adding the non-const copy constructor (in addition to having the const version) are lost. (If only we could ask the author... but past me does not have the answers that present me needs.) It is possible that later changes have obviated the need. Try removing.

Reviewed By: yfeldblum

Differential Revision: D31218444

fbshipit-source-id: 307030df044b4413125365782064066c99570f02

Summary: This diff adds the Rust edenfsctl to our open source build.

Reviewed By: xavierd

Differential Revision: D30788685

fbshipit-source-id: 603caa933ecfc5af0ede7e22f6c7911462da3a65

Reviewed By: iahs

Differential Revision: D31233377

fbshipit-source-id: c61de3936ad2c3d573ef71aca385dda023b38ee7

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