Summary:
Made the following changes AsyncTransport::LifecycleObserver callback
- added `connectAttempt()`, called for each observer when connect is invoked;
- changed `connect()` to `connectSuccess()`, called for each observer when connect is successful;

Reviewed By: bschlinker

Differential Revision: D29962337

fbshipit-source-id: f1d2c0e48b6d7e263466f74c97d701bb9df9b313

Summary: A typo in its name meant it was missing and that `dynamic::operator-(int)` was defined instead.

Reviewed By: ot, luciang

Differential Revision: D31726709

fbshipit-source-id: 42696c958f674de806dd56c3d89ec07dd60db961

Summary:
`retryingJitteredExponentialBackoffDur()` supports `jitter_param=0` (sanctioned in tests, and widely used to disable jitter based on a runtime parameter), but `std::normal_distribution` does not, so just special-case it.

In practice, libstdc++ already returns 0.

Reviewed By: yfeldblum

Differential Revision: D31722687

fbshipit-source-id: d81b1736379c596c4fc352b0067a4ad5788b0f8c

Summary: Make them a bit shorter with a bit less repetition. Performance-wise, trades away two direct calls for one indirect but perfectly-predictable call. And continues to optimize away in non-sanitizer builds.

Reviewed By: luciang

Differential Revision: D31673074

fbshipit-source-id: f6d8b66cf45a81788d1ec0c5b58241f4fc693001

Differential Revision: D31661218

fbshipit-source-id: 48535870ab2b2f86b0d4e9286365fe906110dc3e

Summary: While the baton is used to guard associated memory, if the wait times out, the associated memory is not available. There is no corresponding load-acquire, so marking the timeout may use a store-relaxed rather than a store-release.

Reviewed By: luciang

Differential Revision: D31676286

fbshipit-source-id: dd2474db1ba053337de7e84aa88e7556e630b1ce

Summary: The stripe table, which is a table of atomics, is its own data and does not guard any associated data. It must technically be atomic to avoid technical data race, but all accesses are relaxed.

Differential Revision: D31524230

fbshipit-source-id: 782b515f3845b4567ca258fd8d096f22248d60ff

Summary:
We currently bump it for clang+tsan because the clang implementation of tsan historically implements the historical pre-c++17 rule even post-c++17. But to enable libstdc++ assertions, we must also bump it for for some versions of libstdc++ when assertions are enabled.

The assertions are removed in libstdc++ trunk: https://github.com/gcc-mirror/gcc/commit/dba1ab212292839572fda60df00965e094a11252. They remain in libstdc++11.2.

Reviewed By: ot

Differential Revision: D31593055

fbshipit-source-id: a339306e86452c4bb6d9d821cd28038ab6f49767

Summary: The AsyncSocket move constructor creates a new socket and then populates member fields, such as `byteEventHelper_` and `preReceivedData_`, with the respective values from the old socket. This happens **after** any callbacks in the AsyncSocket constructor (e.g., installed with ConstructorCallback). These callbacks may need the updated values. This diffs offers the possibility to populate new socket member variables early, by adding them to the initializer list of the AsyncSocket constructor used in the move constructor.

Reviewed By: bschlinker

Differential Revision: D31318333

fbshipit-source-id: 731d24ab4c7525e6f28c3aea4d04c9c5e98409ea

Summary:
Spinlocks in user space are generally a bad idea due to tendency to
burn CPU in outlier events. Replace it with SharedMutex instead. The common
case cost could go up a bit should be better overall.

Reviewed By: yfeldblum

Differential Revision: D31654923

fbshipit-source-id: 77d249293458cd740904f777e00be1bd6834b62f

Summary: Added another line to the rsys sample app's `main.cpp`, which forced me to enable sockets and fix errors in order to get it compile and link.

Reviewed By: usikder

Differential Revision: D30192527

fbshipit-source-id: 10eb9714900ca7f7a48c11b5d8308558ca5e8208

Summary:
`folly/io/async:async_base` is not fully migrated to XROS, mitigate futures implementation for now:
* Craft out `fibers::Baton` and `IO pool` dependencies from futures.
* Add futures to CI targets.
* Add build time test to ensure `folly::Future<Unit>` symbols are generated.

This closely follows mitigation in `AROS` branch:
https://www.internalfb.com/code/aros/[a0c19baba13b]/xros/third-party/folly/folly/futures/Future.h

(any suggestions on how to properly proceed with such change are greatly appreciated!)

Reviewed By: egorich239

Differential Revision: D31497625

fbshipit-source-id: c0b2406496ca3c4f69ddadd61dbd1d75f309e8a1

Summary: Workaround for protected default constructor issue

Reviewed By: yfeldblum, mpark, luciang

Differential Revision: D31618662

fbshipit-source-id: f7e2d498f2da01971b4f67dd28897026f405c0fb

Summary: csl_iterator fix

Reviewed By: yfeldblum

Differential Revision: D31664052

fbshipit-source-id: 338b60ddc9575a7d73ee431e9cef848cecfbcdad

Summary: Async socket test workaround for -Werror,-Wsign-compare

Reviewed By: mpark, ispeters, luciang

Differential Revision: D31625210

fbshipit-source-id: 387bf6172d4e518dfd850f456b859605aa9a6d0f

Summary: Address ConstructorCallback -Werror,-Wsign-compare

Reviewed By: ispeters, luciang

Differential Revision: D31625450

fbshipit-source-id: d5be388fc0d62eb715b5a8fe8e5758a8345cbbb0

Differential Revision: D31641668

fbshipit-source-id: a733dbd2dc4e3f20e82d75514ded1a51788d378f

Summary: `DigestBuilder` is a useful companion to `TDigest` (already public), has a simple and well-defined interface, better documentation than most classes in the parent directory, tests, and benchmarks. It doesn't need to be in `detail/`, and it can be useful for use cases not covered by `BufferedStat`, for example when sub-second resolution and a precise flush schedule are required.

Reviewed By: philippv, luciang

Differential Revision: D31643638

fbshipit-source-id: 4f2f54a933942cbe02d08cd63ab5fc04f13630e3

Summary: Symmetric operators are done using free or non-member operators. This ensures that whatever conversions could happen to the RHS can also happen to the LHS, symmetrically.

Reviewed By: philippv

Differential Revision: D31582089

fbshipit-source-id: ecae61bc810ee9538b1c2b738c58d4e9e01f1483

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

Similar to CO_TEST_[F|P], adding CO_TYPED_TEST which allows test cases to use co_await/co_return and blocks on the Task<> separately.

Reviewed By: iahs

Differential Revision: D31621981

fbshipit-source-id: 83618de2d106954bde819d90afde0c0140674d54

Reviewed By: iahs

Differential Revision: D31271338

fbshipit-source-id: 10cbd083c4da7461a43d4d0a9d4ab5455dcee270

Summary: While `wake()` is an accurate-enough description of what the function in question does, the actual name of the function is `post()`.

Reviewed By: luciang

Differential Revision: D31617933

fbshipit-source-id: b45f062dccada3cedab2e2b7e7734f6b0b501e63

Summary:
`hg debugapi` now provides easier ways to test edenapi endpoints.
Remove the `edenapi/tools` to reduce code bloat. This also unblocks removing
`To/FromJson` complexity so adding new endpoints become easier.

Reviewed By: yancouto

Differential Revision: D31465796

fbshipit-source-id: fdc0a47b4302c876e78455101068f27949d1b645

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

For the `nextThread_` field, which may be mutated within `pickThread` in any number of threads concurrently. While `pickThread` is only ever called with a shared lock held, the shared lock does not actually help with concurrent mutations.

Since the mutations of `nextThread_` by `pickThread` is always a `std::atomic::fetch_add` with `std::memory_order_relaxed`, and since that case is a bit more nicely solved with `folly::relaxed_atomic`, switch to that.

Reviewed By: ot

Differential Revision: D6290451

fbshipit-source-id: e473fa6321e462c9b3df9d2bd9650967cca3444a

Summary:
we are currently capture the ID of the thread that is spawning IO threads, not
the ids of the IO threads themselves. Fix it.

Reviewed By: yfeldblum

Differential Revision: D31577084

fbshipit-source-id: 869f9ad20ad379327db513501392bd6bc1ced7e8

Summary: I'm not sure this API is actually used anywhere, but the implementations don't account for cases where the underlying socket is unreadable but setting a read callback would immediately provide data.

Reviewed By: simpkins

Differential Revision: D25324200

fbshipit-source-id: 4176432feea09a4d1387b9025f485e537a5b8da5

Summary: Avoids temporary array

Reviewed By: yfeldblum

Differential Revision: D31547083

fbshipit-source-id: e8c8246145428079a00999da7b3d2c4f59105300

Summary:
Add code to capture client alpns from client hello packet and store them in
ssl socket object for later logging.

Reviewed By: AjanthanAsogamoorthy

Differential Revision: D31176714

fbshipit-source-id: 888fd9949ede5209234bb3ab1959a6f9c14043b2

Summary:
`folly::RequestContext::try_get()` might deadlock if accessor to all threads is
held alive.

Reviewed By: amlannayak

Differential Revision: D31496646

fbshipit-source-id: 6edfd0a54f8bfaf72218d78ba1a6c09dc92a8e63

Summary:
Currently, both Merge and MergeChannel use a folly::F14FastSet of channel bridge unique pointers. In order to look up items inside this hash set by raw pointer, a custom equality and hash function are provided. These functions just check for equality of the underlying raw pointers (and run std::hash on the raw pointers).

This has turned into a large performance bottleneck. For some reason, folly::F14FastSet's performance tanks when using custom equality/hash functions. The performance seems to get worse as more items are added. In tests I was running, a single lookup took over 5ms with a set of 200k items.

This diff removes the custom equality/hash functions for ChannelBridge. Merge and MergeChannel are changed to use hash sets of raw pointers. Lifetime is managed outside of the F14FastSet (by explicitly deleting the raw pointers after items are removed from the set).

Reviewed By: aary

Differential Revision: D31426627

fbshipit-source-id: 1ce7fd1b431704f6353b9ea3d689cee002dd9bdc

Reviewed By: yfeldblum

Differential Revision: D31414552

fbshipit-source-id: 0a814de998d88950f5e6e61c23b20f40c2eb0a37

Summary:
We have cases where the C++ -> Lua calls are not properly following the calling convention and the pointer to the previous normal stack frame is not correctly pushed after the lua call. This results in segfaults when we try to walk the normal stack.

Stack frame addresses for the normal stack frames should always be increasing. A simple fix is check whether the next stack frame address <= starting stack frame address. If it is, this indicates the end fo the stack (nullptr) or likely stack corruption, as in the case above.

This means that we might miss out on the stack frames right before the stack frame that breaks the calling convention, but we should correctly get the rest of the async stack trace before this frame, and the stack frames after this frame.

Reviewed By: yfeldblum

Differential Revision: D30907903

fbshipit-source-id: 7d78b53570fd24dbb23b4fc49afa995d44c9e549

Summary:
Using a per-thread CPU clock when burning CPU time (instead of the system
clock), so measurements should be accurate independently of the load on the
system.

Reviewed By: yfeldblum

Differential Revision: D31436995

fbshipit-source-id: 3e732e2f4d2c04846dcafef32b00a87617c940b8

Summary:
Fixes the following warning:

```
folly/lang/ToAscii.h(224): warning C5219: implicit conversion from 'T' to 'double', possible loss of data
        with
        [
            T=size_t
        ]
folly/lang/ToAscii.h(236): note: see reference to function template instantiation 'size_t folly::detail::to_ascii_size_clzll<10>(uint64_t)' being compiled
folly/lang/ToAscii.h(349): note: see reference to function template instantiation 'size_t folly::detail::to_ascii_size_route<10>(uint64_t)' being compiled
folly/lang/ToAscii.h(358): note: see reference to function template instantiation 'size_t folly::to_ascii_size<10>(uint64_t)' being compiled
```

Reviewed By: luciang

Differential Revision: D31314625

fbshipit-source-id: b32a566b67d2f04225b59ee682931d5f8d9ede1e

Summary:
Not all systems have a libdwarf that supports dwarf 5. We only need a single tag from it, so just define it when needed.
Fixes: https://github.com/facebook/folly/issues/1654

Reviewed By: luciang

Differential Revision: D31423305

fbshipit-source-id: 89fecccb5ac68830a33b1fad51210cbaa9754bf8

Reviewed By: AjanthanAsogamoorthy

Differential Revision: D31399112

fbshipit-source-id: ea98963536de42136642809d2bd07b9567464f68

Summary:
Getting an `std::string` out of the data in a `IOBuf` chain is a common operation in tests, logging, and at interface boundaries. Currently there isn't an easy way to do it, so either the same boilerplate is replicated everywhere, or people resort to `coalesce().str()`, which is inefficient (it can end up copying the data twice) and non-`const`.

Add methods to append and convert to any char container, like `string`, `fbstring`, `vector<char>`, ...

Reviewed By: philippv

Differential Revision: D31385345

fbshipit-source-id: 8a331771786f7bf1043b59d5c36ac4051e442531

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