Summary: Ensure that threshold is not 0, otherwise when capacity < 10, threshold is 0, which can lead to consumers never transferring credit to producers.

Differential Revision: D26791831

fbshipit-source-id: 741bcf17de18198e43471d4b36d98c79288652fb

Summary: These cause unused variable warnings on other platforms.

Reviewed By: mzlee

Differential Revision: D26771614

fbshipit-source-id: 9170c0da97375682624ee73fe422f34860f35a80

Summary:
On Apple platforms, some of the ucontext methods used here are
deprecated.

Reviewed By: yfeldblum, snufkinsnorka

Differential Revision: D26765225

fbshipit-source-id: 92c7e554b1d1e98b7b8566079a0cb3a0e8afc2d3

Summary: Depending on inlining of std library primitives (e.g. coroutine_handle) it's possible to have more frames in the stack trace.

Reviewed By: yfeldblum

Differential Revision: D26793792

fbshipit-source-id: 44fb1344353e29ec92559ee34740157373112f8f

Summary:
When the given deadline to futexWaitUntil() is less than the idle
timeout that controls purging, MemoryIdler should not purge JEMalloc arenas.
Fix a bug where if the deadline is less than the idle timeout, purging happens
100% of the time unconditionally.

Reviewed By: mogeb, davidtgoldblatt, jalatif

Differential Revision: D26784786

fbshipit-source-id: 316ef96658d0cc2263b973b0b7c345605784eb36

Summary:
With the exception of std::string, nothing else string-like can be
optimized further than a copy. So, create a generic Stringish constructor
that copies .size() elements from .data(), where .data() has a value type
of char.

Reviewed By: yfeldblum

Differential Revision: D5407445

fbshipit-source-id: acf709f07e73bb5bef3f124169c81d76edefa52c

Summary:
Dropping support for earlier zstd versions allows us to remove all of the version check logic.
Zstd-1.4.0 was released in April 2019, and it stabilized a large portion of our API.

Reviewed By: yfeldblum, Cyan4973

Differential Revision: D26585060

fbshipit-source-id: 3e8bd3aa1930c993cc0f2e8fc147db66de9dfdda

Summary:
This modifies the existing `co_bt` gdb script to make use of the new async stack traces available with folly::coro. This adds 2 new commands to gdb:

- `co_bt` with no arguments print the async stack trace for the current thread if there is an async operation in progress. This will print the normal stack frames interleaved with async stack frames as appropriate.
- `co_async_stack_roots` will print the `AsyncStackRoot` pointers available on the current thread
- `co_bt [ADDRESS]` will print the async stack frames starting at the provided `AsyncStackRoot` pointer

Reviewed By: andriigrynenko

Differential Revision: D26719625

fbshipit-source-id: 8edf6ab0851ab92614b3dbeafdf50a517dcc3a61

Summary: Add support for both <coroutine> and <experimental/coroutine> headers. Also add support for __cpp_impl_coroutine (which is required by the standard).

Reviewed By: yfeldblum

Differential Revision: D26745085

fbshipit-source-id: 0bf932e2e30d5b105b1559d817563946fcd3b573

Summary: As a standing rule, let us not have our things be susceptible to ADL except when we very consciously and very specifically want an extension point.

Reviewed By: aary

Differential Revision: D26678138

fbshipit-source-id: 9f845dbc5ed95aaecf4d6cd256aedd0b240e00d3

Summary: Depending on the version of the std library, coro types may be in std or std::experimental namespace. Use coro namespace instead to make switching library implementation easier.

Reviewed By: yfeldblum

Differential Revision: D26744795

fbshipit-source-id: 8856b901d4d757bf378acb56f236135feb0c5488

Summary: Fix github actions builds for projects depending on zstd

Reviewed By: wez

Differential Revision: D26743251

fbshipit-source-id: a3fd8a14750227d025bff763cca8aa683b26a422

Summary:
Callback destruction can involve user logic.  In practice, we
found quite a bunch of patterns like:

```
executor->add([x = someGuardObjectThatTriggersWorkInDtor] {
  ...
});
```

So ensure that dtor is

* Executed under `RequestContextScopeGuard`,
* Protected from leaking unhandled exceptions.

Reviewed By: ot, luciang

Differential Revision: D26744394

fbshipit-source-id: 5fcca0287a98de919c3649a9613e6d54cc1a1ba3

Use ExecutionObserver in EventBase to monitor function not executed EventBaseAtomicNotificationQueueby in EventBase

Summary:
Our service schedules tasks (eSemiFuture/coroutine) on SerialExecutor on top of IOThreadPoolExecutor. When using EventBaseWatchdog to locate long running tasks, I found some long running tasks were not observed by PerThreadExecController. After some investigation, I found there are 2 cases in EventBase that tasks are not executed by handlerReady in EventBaseAtomicNotificationQueue.

1. Short-circuit scenario in runInEventBaseThread which bypasses EventBaseAtomicNotificationQueue.
2. If notification Queue is marked 'internal', some events may be ran "manually" in loopBody.

As a result, the observer logic in EventHandler (EventBaseAtomicNotificationQueue derives from EventHandler) is passed.

Reviewed By: andriigrynenko

Differential Revision: D26563459

fbshipit-source-id: e2741cff373c89a5cd438904f910b23a64fad653

Summary:
Adding support for write and socket timestamps by introducing `ByteEvent` that can be delivered to observers.
`AsyncTransport::WriteFlags` has long had timestamping related flags, such as `TIMESTAMP_TX`, but the code required to act on these flags only existed in proxygen. This diff generalizes the approach so that it works for other use cases of `AsyncSocket`.

This diff is long, but much of it is unit tests designed to prevent regressions given the trickiness of socket timestamps and `ByteEvent`.

**Each `ByteEvent` contains:**
- Type (WRITE, SCHED, TX, ACK)
- Byte stream offset that the timestamp is for (relative to the raw byte stream, which means after SSL in the case of AsyncSSLSocket)
- `steady_clock` timestamp recorded by AsyncSocket when generating the `ByteEvent`
- For SCHED, TX, and ACK events, if available, hardware and software (kernel) timestamps

**How `ByteEvent` are used:**
- Support is enabled when an observer is attached with the `byteEvents` config flag set. If the socket does not support timestamps, the observer is notified through the `byteEventsUnavailable` callback. Otherwise, `byteEventsEnabled` is called
- When the application writes to a socket with `ByteEvent` support enabled and a relevant `WriteFlag`, SCHED/TX/ACK `ByteEvent` are requested from the kernel, and WRITE `ByteEvent` are generated by the socket for the *last byte* in the write.
  - If the entire write buffer cannot be written at once, then additional `ByteEvent` will also be generated for the last byte in each write.
  - This means that if the application wants to timestamp a specific byte, it must break up the write buffer before handing it to `AsyncSocket` such that the byte to timestamp is the last byte in the write buffer.
- When socket timestamps arrive from the kernel via the socket error queue, they are transformed into `ByteEvent` and passed to observers

**Caveats:**
1. Socket timestamps received from the kernel contain the byte's offset in the write stream. This counter is a `uint32_t`, and thus rolls over every ~4GB. When transforming raw timestamp into `ByteEvent`, we correct for this and transform the raw offset into an offset relative to the raw byte offset stored by `AsyncSocket` (returned via `getRawBytesWritten()`).
2. At the moment, a read callback must be installed to receive socket timestamps due to epoll's behavior. I will correct this with a patch to epoll, see https://github.com/libevent/libevent/issues/1038#issuecomment-703315425 for details
3. If a msghdr's ancillary data contains a timestamping flag (such as `SOF_TIMESTAMPING_TX_SOFTWARE`), the kernel will enqueue a socket error message containing the byte offset of the write ( `SO_EE_ORIGIN_TIMESTAMPING`) even if timestamping has not been enabled by an associated call to `setsockopt`. This creates a problem:
    1. If an application was to use a timestamp `WriteFlags` such as `TIMESTAMP_TX` without enabling timestamping, and if `AsyncSocket` transformed such `WriteFlags` to ancillary data by default, it could create a situation where epoll continues to return `EV_READ` (due to items in the socket error queue), but `AsyncSocket` would not fetch anything from the socket error queue.
    2. To prevent this scenario, `WriteFlags` related to timestamping are not translated into msghdr ancillary data unless timestamping is enabled. This required adding a boolean to `getAncillaryData` and `getAncillaryDataSize`.

Differential Revision: D24094832

fbshipit-source-id: e3bec730ddd1fc1696023d8c982ae02ab9b5fb7d

Summary:
Wrapper around `folly::netops` methods that makes it easier to mock these methods in unit tests.

When we want to mock out calls to `folly::netops` we currently:
- Use methods like `getSockOptVirtual` and `setSockOptVirtual`
- Mock part of the socket, like in the tests in `AsyncSSLSocketWriteTest`

I've the latter makes the tests particularly error prone, since we're mocking the object that's also under test.

This change introduces `netops::Dispatcher`, which is a class containing all of the functions in `folly::netops`:
- By default `AsyncSocket` uses a default, static instance of `Dispatcher` that forwards calls to the original `netops::` calls (e.g., calling `netops::Dispatcher::sendmsg` results in a call to `netops::sendmsg`.
- When a test wants to mock a a `folly::netops` call, it can call `setOverrideNetOpsDispatcher` to insert a mock `netops::Dispatcher`. I use it in this manner in D24094832

Differential Revision: D24661160

fbshipit-source-id: e9cb4ed28ffe409c74998a1c9501c0706fc853e0

Summary:
During the wangle accept process and in a few pieces of application code we transform one type of `AsyncSocket` to another, potentially *after* a write has occurred.

Since we do not currently carry `appBytesWritten` and `rawBytesWritten` during transformations, those values may not represent all bytes written. Likewise, if we transform from a `AsyncSSLSocket`, we lose count of the number of raw bytes written.

It's very difficult to reason about whether these problems will actually manifest, so I'd prefer to just guard against it.

With this change, we explicitly track the number of bytes written to the socket by incrementing a counter in `sendSocketMessage`, which is used by both `AsyncSocket` and `AsyncSSLSocket`. In addition, we copy the appBytesWritten and rawBytesWritten during socket moves.

Reviewed By: yfeldblum

Differential Revision: D24551958

fbshipit-source-id: 88416114b52931ff3ceef847401d556ccf0ab664

Summary: Both `AsyncSocket` and `AsyncSSLSocket` currently have code to generate a socket message and control messages with ancillary data. Merge this code into a new function in `AsyncSocket`.

Differential Revision: D24096351

fbshipit-source-id: 87d90648c10c87832f868e322acf59c97b8ac8b7

Summary:
Move `ready_awaitable`, `variant_awaitable` types to `folly/experimental/coro/Coroutine.h`, which reexports the foundational vocabulary coroutine helper types and is a suitable place for these vocabulary coroutine helper types.

`ready_awaitable` is an awaitable which is ready and has a value or, if of void, which is just ready. `variant_awaitable` is an awaitable composed of one of several possible backing awaitables.

Reviewed By: aary

Differential Revision: D26270528

fbshipit-source-id: e98f64b3d3ffaf5bbd322397a41bb5fe85a6bb55

Summary:
`folly::format` is a problematic API because it returns a `Formatter` object that may store references to arguments as its comment warns:

```
 * Formatter class.
 *
 * Note that this class is tricky, as it keeps *references* to its lvalue
 * arguments (while it takes ownership of the temporaries), and it doesn't
 * copy the passed-in format string. Thankfully, you can't use this
 * directly, you have to use format(...) below.
```

This has negative safety and performance (encourages reuse of the same formatter) implications because contrary to what the comment says you can use the object directly since it's returned from `folly::format`. For example
```
auto f = folly::format(std::string("{}"), 42);
f.str();
```
is a UB with no compile-time diagnostic (only caught by ASAN).

It's also unnecessary because the `Formatter` object is usually converted to string straight away via `str()` or written to an output stream. Reusing the formatter doesn't make much sense either because the expensive part is formatting, not capturing arguments.

This diff deprecates `folly::format` suggesting `fmt::format` as a potential replacement. `fmt::format` doesn't have the above problem because arguments are always in scope. It also has the following advantages:

* Better compile times.
* Compile-time format string checks.
* Compatibility with C++20 `std::format`.
* Better performance, particularly with format string compilation which eliminates format string processing overhead altogether.
* Smaller binary footprint.

Also remove `folly::writeTo` which is no longer used and the `format_nested_fbstrings` benchmark which is identical to `format_nested_strings` since there is no `fbstr()` any more.

Reviewed By: yfeldblum

Differential Revision: D26391489

fbshipit-source-id: f0309e78db0eb6d8c22b426d4cc333a17c53f73e

Summary: Follow a convention that function object types with corresponding function object instances be named with a `_fn` suffix.

Reviewed By: ericniebler

Differential Revision: D26674781

fbshipit-source-id: f8a3b8f18677c905897da8bae38cc76693146073

Summary: Use of `std::coroutine_traits` and `std::experimental::coroutine_traits` can get awkward and we do not actually need the flexibility. Just define member type aliases `promise_type`.

Reviewed By: andriigrynenko

Differential Revision: D26706363

fbshipit-source-id: 0cdb59d542a64ff85d8a126003a014b7b6be3134

Summary: Invokers for `begin` and `end` with `std::begin` and `std::end` in scope.

Reviewed By: ericniebler

Differential Revision: D26683890

fbshipit-source-id: 79e57b235c847b5bea29e2e6aac767bdfcef72e8

Summary: Namely, let the backports of `std::size`, `std::empty`, and `std::data` be function objects in folly to eliminate possibility of ADL overloading.

Reviewed By: ericniebler

Differential Revision: D26681127

fbshipit-source-id: 0c2868f25818afca7efd6b2337cb398daa9bb7f3

Summary: Add FOLLY_PORT_WIN32_OPEN_BINARY define

Reviewed By: yfeldblum

Differential Revision: D26693403

fbshipit-source-id: 51fb9ceef31cffdeff691ad0eb49939725cc047b

Summary: Reexport remaining names, including `noop_coroutine`, from `folly/experimental/coro/Coroutine.h`, which wraps inclusion of `experimental/coroutine`.

Differential Revision: D26227580

fbshipit-source-id: b7ea0bb0bb7447bf4327b2f178c51db544f70f46

Summary: TSIA

Differential Revision: D26697902

fbshipit-source-id: bd0a552959474c0efa6167e8da1ed31916c77346

Summary: The static cast and forward were backwards. Previously it happily converted an rvalue to a const lvalue. Now it causes the exact same static_assert failure as std::forward in every rvalue->lvalue case.

Reviewed By: yfeldblum

Differential Revision: D26680263

fbshipit-source-id: f1ca4c4bfdd6333d24fe3c406d5373a2f72dea31

Summary: There are no correct uses of the catch-all overload of `folly::exceptionStr`. Every use is a bug of some kind, leading to the impression that this overload ought to be removed.

Differential Revision: D26539622

fbshipit-source-id: dc2ca0781ea02f1327a334bb1fe2e533fa46d1b3

Summary: Prevent a race condition where a session's reference count can be decremented to 0 (causing the session to be freed) by one thread before another thread can increment the reference count.

Reviewed By: mingtaoy

Differential Revision: D26614966

fbshipit-source-id: 6c55321becfc1a3467f57c692065680a32ac21f3

Summary:
BoundedAsyncPipe::write() accepts arguments by-reference, so even
these constants may be out-of-scope by the time the coroutine actually runs,
causing use-after-scope problems which are detected by ASAN.

Wrapping in co_invoke allows us to scope the parameter so that it
lives long enough.

Reviewed By: lxfind

Differential Revision: D26649913

fbshipit-source-id: 5bc6b7f64a5e75c9386b245fa3fd1484efaf1d13

Summary:
This is needed if we have an AsyncStackRoot pointer, and we
want to call both `getTopFrame()` and `getNextRoot()`
(e.g. walking async stacks) without const-casting the pointer.

Reviewed By: yfeldblum

Differential Revision: D26675131

fbshipit-source-id: 84de25c67d563e118483d67d0fedb4ea7aef2604

Summary: Currently there is an extension point `folly_co_invoke` for providing customizations for `co_invoke`. But `tag_invoke` is intended as a generic mechanism for providing namespaced customizations. So let us use that.

Reviewed By: ericniebler

Differential Revision: D26674580

fbshipit-source-id: b1baea04996f162699510c3aba8d2c330fcf34bb

Reviewed By: zertosh

Differential Revision: D26660179

fbshipit-source-id: bc0ae7deeb3a3097bfb77cbf0bc471157f586326

Summary: As per title, stub it out in a way that will just trigger exceptions for everything not yet implemented.

Reviewed By: yfeldblum

Differential Revision: D26579892

fbshipit-source-id: 5bfc20b1f6737bbda80616ea1407a5cf108be3c3

Summary: Choose a single strategy for guarding coro files. Namely, all includes are unconditional, but otherwise the bodies of all headers, sources, and tests are conditional.

Reviewed By: ericniebler

Differential Revision: D26647625

fbshipit-source-id: 33eeb12fb231bd7ae7fe5cb97ead16ab017b15f5

Summary:
There is a Most Vexing Parse problem in `folly/MapUtil.h`:

```
xplat/folly/MapUtil.h:44:75: error: expected expression
  return (pos != map.end()) ? (pos->second) : M(std::forward<Value>(dflt));
                                                                          ^
```

Fix the issue by replacing paren-init with `static_cast`.

Reviewed By: yfeldblum, ispeters, ot

Differential Revision: D26610359

fbshipit-source-id: 89842b9b68cebaaab43ea5f82abe7e500f98ff2c

Summary:
Newer libiberty has limits that over constrain
the size of symbols that can be demangled.
This applies the same adjustment in the default
platform009 demangler, done in D26380825

Differential Revision: D26617797

fbshipit-source-id: 8d3e72a0807aa9ecff18d26f38c1acb83f9c051b

Summary:
Right now we have a single option verifyPeer_(SSLVerifyPeerEnum) that
controls how verification is done regardless of how the ssl context is
inevitably used (client or server). This is confusing for our users since it
is 1. unclear of what the current values mean 2. It is unclear that setting an
option such as VERIFY_REQ_CLIENT_CERT also sets your verification mode when
running as a client.In order to make this api more clear for
our users we separate out this enum to two separate enums for client and
server. When this is passed to openSSL we still pass the same single mode int.

Reviewed By: mingtaoy

Differential Revision: D18308192

fbshipit-source-id: 5d49d3dc5117075a55681cf67b5f8e72b5e62c89

Summary:
Original commit changeset: b48fe4683165

Our application can't terminate since this change was committed. 100% reproducible.

Reviewed By: WillerZ

Differential Revision: D26621716

fbshipit-source-id: 571ecd9a6f5286469877bf510f1f55b036df9217