Summary: All standard containers have an allocator_type typedef; so should sorted_vector_map and sorted_vector_set

Reviewed By: yfeldblum

Differential Revision: D13648217

fbshipit-source-id: ccf0b74af88f77b2b28620317cba8a868e9f9b0f

Summary: [Folly] Fix crash in `SingletonRelaxedCounter` when recreating threads.

Reviewed By: andriigrynenko

Differential Revision: D13645448

fbshipit-source-id: dea09925f1943ebf2141d69b791a9259524c19e1

Summary:
This adds a simple benchmark to measure the throughput of calling `Baton::timed_wait` with later fulfillment of Baton without hitting the timeout. This benchmark is useful to make sure that we don't regress when migrating to HHWheelTimer.

It adds 3 case with 1, 5 and 10000 different timeout values used. Below are the results of running the benchmarks:

```
============================================================================
folly/fibers/test/FibersBenchmark.cpp           relative  time/iter  iters/s
============================================================================
FiberManagerCancelledTimeouts_Single_300                   366.57ms     2.73
FiberManagerCancelledTimeouts_Five                         365.44ms     2.74
FiberManagerCancelledTimeouts_TenThousand                  693.06ms     1.44
============================================================================
```

Note, that the 10k case is slower because internally `TimeoutController` has `O(num_timeouts)` loop for looking up the correct queue.

Reviewed By: jmswen

Differential Revision: D13624361

fbshipit-source-id: 4c2324229f524b55d9cf2371ec2acca35db6f4ff

Summary:
Currently we call `steady_clock::now` twice within just few instructions (one in `setScheduled` and one in `calcNextTick`) which adds unnecessary overhead.

This diff makes us call it only once and use it for both computation of the deadline and tick number.

This allows to achieve almost ~2x improvement in perf.

Reviewed By: jmswen, vitaut

Differential Revision: D13624360

fbshipit-source-id: 40bc3b3ad5123d22a5edcabd60d91c0f7efcbda7

Summary:
This function is being overridden in only one class (with a duplicate) that is used in only a single test with no clear semantics of what is being tested (the only effect it has is that cascading logic will see 0, which can be achieved with a simple sleep).

Removing this customization point allows us to avoid doing additional call to steady_clock::now per each timeout (stacked diff) and thus improving performance by ~2x (measured as part of Fibers benchmark after migrating FiberManager to use HHWheelTimer, also stacked).

Reviewed By: jmswen

Differential Revision: D13624362

fbshipit-source-id: ef3abd066d2a4f46b369f65d64dd58399ebf5e46

Summary: deleting a stale benchmark report

Reviewed By: yfeldblum

Differential Revision: D13632256

fbshipit-source-id: b3ff7e109d51389179cd48c7260ab16cb9eb6e22

Summary:
`TimekeeperScheduledExecutor` adapts a (non-Scheduled) `Executor` to provide a `ScheduledExecutor` interface using a `Timekeeper`.

Note this executor does not hold onto a pointer to the `Timekeeper`, but rather relies on the one returned by the `getTimekeeper` callback arg to `create` (default `folly::details::getTimekeeperSingleton`) when scheduling a task in the future, raising a `TimekeeperScheduledExecutorNoTimekeeper` exception if it returns null.

Reviewed By: andriigrynenko

Differential Revision: D13005248

fbshipit-source-id: fc075026f00de763cf5e67c0d7f5e657704e04a3

Summary:
- `std::random_shuffle` is deprecated in C++14 and removed in C++17.
- While `Folly` only depends on C++14, it should not hinder users from
  building in C++17 mode.
- To support users building with C++17 where `std::random_shuffle` is
  removed from the standard library, migrate the one call site to use
  `std::shuffle`.
Pull Request resolved: https://github.com/facebook/folly/pull/993

Reviewed By: Orvid

Differential Revision: D13620930

Pulled By: yfeldblum

fbshipit-source-id: 630d1125155e022f4b3e804f92c02ec663a86c3b

Summary:
Disallow initializing folly::Optional with nullptr as if it were
folly::none. The previous behavior was a footgun when transitioning to
C++17's std::optional. For example, given:

```
folly::Optional<bool> o1 = nullptr;
std::optional<bool> o2 = nullptr;
```

o1 would be none, but o2 would have the value `{false}`.

This diff makes the former illegal, preventing behavior changes
when transitioning to std::optional.

Reviewed By: yfeldblum

Differential Revision: D12843022

fbshipit-source-id: 165d19a963672c04d9ec687cb687ca89f1837e21

Summary:
The CoroTest.cpp file had some tests that were failing under Clang optimised builds due to a compiler bug.

This rolls back those work arounds to re-expose the bug as a way of validating that the bug has been fixed.

Reviewed By: tks2103

Differential Revision: D13383774

fbshipit-source-id: ac219c6ed0a0c8c3b8c3c06e3d01e5ed4ade81bc

Reviewed By: yfeldblum

Differential Revision: D13603396

fbshipit-source-id: 90d2ce9e4d3cfc681e27df84e8e989c7cee182cc

Summary: The code is not calling posix_spawn(...) correctly.

Reviewed By: yfeldblum

Differential Revision: D13596190

fbshipit-source-id: 266522ec2387b6e2294fc5899aa85afc19d8d919

Summary:
Minor improvements to `Rcu.h`:
* Spell out the first use of RCU for the sake of people who are not familiar
  with the abbreviation.
* Correct the default template argument type in the comment: it's `RcuTag`, not
  `void`.
* Don't expose `rcu_token` constructor to the users because it's only supposed
  to be obtained via `lock_shared`.
* Make other single-argument constructors explicit to prevent undesirable
  conversions.
* Parameterize `rcu_token` on the tag type to prevent cross-domain use.

Reviewed By: yfeldblum

Differential Revision: D13510133

fbshipit-source-id: d5d214cfa3b30d0857c14ac293da6e4310db1100

Summary:
Since we require C++14 in Folly and use `std::enable_if_t` in some places, there
is no need for the `_t` workaround. Replace `_t<enable_if<...>>` with
`enable_if_t<...>`.

Reviewed By: yfeldblum

Differential Revision: D13511564

fbshipit-source-id: 314b4a63281ce6b8275174ae89fab5fba1101bfb

Summary: [Folly] `SingletonRelaxedCounter`, a singleton-per-tag relaxed counter.

Differential Revision: D13149336

fbshipit-source-id: 7cf0144758e9595e188465137a336d712c5d9a76

Summary: [Folly] Cut unused `hazptr` dep on `Singleton`.

Reviewed By: magedm

Differential Revision: D13586564

fbshipit-source-id: e0e87807f51f0d050e045961b5e40e600026f182

Summary:
[Folly] Alias `std::apply` for libc++ if c++17, and for msvc.

Fixes #987.

Reviewed By: gkmhub

Differential Revision: D13562821

fbshipit-source-id: b1fef92eed24ce201e50dda72d1ee8b6db9ed6dd

folly/synchronization/LifoSem: fixed race condition between tryRemoveNode and shutdown by checking the lock in shutdown (#989)

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

Original post: https://fb.workplace.com/groups/560979627394613/permalink/1370192126473355/

There was a bug where we weren't checking the isLocked bit when setting the isShutdown bit. Thus, tryRemoveNode would acquire the lock, shutdown would set the shutdown bit, and then tryRemoveNode would release the lock via a direct store which accidentally cleared the shutdown bit.

The new code wait loops in shutdown until the lock is cleared.

Reviewed By: yfeldblum, djwatson

Differential Revision: D13586264

fbshipit-source-id: 52139df8d7880a60039b6dab810898e0546479dc

Summary: Stumbled upon some unused includes. Remove them.

Reviewed By: yfeldblum, stevegury

Differential Revision: D13549301

fbshipit-source-id: 9e18e3764baff02d8a077a81124633ea21698dbb

Summary: in D13274704 default has been changed to OFF. fixing comment

Reviewed By: yfeldblum

Differential Revision: D13590584

fbshipit-source-id: af1bac2b866aa55f9645ce33da6e8850cd136d31

Summary: Erase if and only if key k is equal to expected

Reviewed By: magedm

Differential Revision: D13542801

fbshipit-source-id: dd9e3b91a7e3104b18315043d5f81b6194a407eb

Summary: Add takeOwnershipBenchmark IOBuf benchmark

Reviewed By: yfeldblum

Differential Revision: D13580855

fbshipit-source-id: 6c8e81e580daf8e097be03235f3720e79eadc21f

Summary:
Expose the IOBuf SharedInfo::userData

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D13577451

fbshipit-source-id: b52ebbf77d00594a04c26e629d5c208e92801d93

Summary:
The folly::coro::Task coroutine type now captures the current RequestContext when the coroutine suspends and restores it when it later resumes.

This means that folly::coro::Task can now be used safely with RequestContext and RequestContextScopeGuard.

Reviewed By: andriigrynenko

Differential Revision: D9973428

fbshipit-source-id: 41ea54baf334f0af3dd46ceb32465580f06fb37e

Reviewed By: mengz0

Differential Revision: D13580163

fbshipit-source-id: 195e3007c6cbf4bf7281435c48a9b6f6c6eada5b

Summary:
Before this change one could write:
  SemiFuture<void> f() {
    co_await f1();
    co_await f2();
  }
where SemiFuture coroutine would have semantics of an InlineTask (f1 called inline, f2 would be called on the executor which completes f1). This doesn't match the semantics of SemiFuture with deferred work (both f1() and f2() called on the executor that was passed to SemiFuture's via).

Drop support for SemiFuture coroutines, because that isn't used anywhere except for toSemiFuture function.

Reviewed By: lewissbaker

Differential Revision: D13501140

fbshipit-source-id: d77f491821e6a77cef0c92d83839bff538552b32

Summary:
Adds a simple SharedMutex type to the folly::coro namespace.

The `co_[scoped_]lock[_shared]()` methods return semi-awaitables that require the caller to provide an executor to resume on in the case that the lock could not be acquired synchronously. This avoids some potential issues that could occur if the `.unlock()` operation were to resume awaiting coroutines inline.

If you are awaiting within a `folly::coro::Task` then the current executor is implicitly provided. Otherwise, the caller can explicitly provide an executor by calling `.viaIfAsync()`.

The implementation has not been optimised and currently just relies on a `SpinLock` to synchronise access to internal state.

The main aim for this change is to make available a SharedMutex abstraction with the desired API that applications can start writing against which we can later optimise as required.

Reviewed By: andriigrynenko

Differential Revision: D9995286

fbshipit-source-id: aa141ad241d29daff2df5f7296161517c99ab8ef

Summary: As interim steps to codemod to.

Reviewed By: yfeldblum

Differential Revision: D13568657

fbshipit-source-id: b143b5bab0a64c196892358a30fce17037b19b21

Summary:
Skip F14Map.continuousCapacity* tests if intrinsics are not
available, and don't use c++17 API in the test.

Reviewed By: yfeldblum

Differential Revision: D13575479

fbshipit-source-id: 1cbbd10990ba5f0cc64ad1b29d4701b700dd16be

Summary:
This diff imports farmhash.h and farmhash.cc from
https://github.com/google/farmhash and updates the public_tld license
file accordingly. Build integration and namespace changes will occur in
later diffs.

Reviewed By: yfeldblum

Differential Revision: D13436553

fbshipit-source-id: 7a081032cb35a1a3e1cd14e2edf2685906956396

Summary:
Adds support for zstd-1.3.8 so OSS builds work.
We can support zstd < 1.3.8 for some time with this small compatibility layer.
I plan on always supporting at minimum the latest 2 zstd versions.

Reviewed By: yfeldblum

Differential Revision: D13569550

fbshipit-source-id: 67d53c9ad0051a889b810c9ad46a2f349122cf7e

Summary:
Because it wasn't clear for non-python developers. And this document is referenced in Spark AR documentation.
Pull Request resolved: https://github.com/facebook/folly/pull/988

Reviewed By: yfeldblum

Differential Revision: D13570180

Pulled By: Orvid

fbshipit-source-id: 2e1f787c5e1bb50a90c85a12e6801a79a3b46999

Summary: Add AsyncUDPSocket support for sendmmsg

Reviewed By: djwatson

Differential Revision: D13521601

fbshipit-source-id: 89382e18943e01012ff1e56a40f655d634a6e146

Summary: [Folly] Add a missing blank line (style nit).

Reviewed By: lewissbaker

Differential Revision: D13571222

fbshipit-source-id: 1dd23f4fc895e5698f94be6b2cbf90a9f30aae41

Summary: There's no need to extensively call into steady_clock, because the time is unlikely to change. And if it does change, then it means that we'd do incorrect math (like firing timeout 10ms earlier).

Reviewed By: djwatson, stevegury

Differential Revision: D13541503

fbshipit-source-id: cc46c8a6bd6a72544803a22d16235be54fa94cc4

Summary: There's no need to distinguish between them (it only adds complexity by having two modes: schedules vs running).

Reviewed By: djwatson

Differential Revision: D13541505

fbshipit-source-id: 7cb2c3fb9ba4e3b191adee37ad1d28f471378f85

Summary:
Current logic will use last processed tick as next tick if we are inside of timeout handling.

However, this is wrong in two ways:
* cascading logic would compute number of ticks until expiration from real current time, however it will use `lastTick_` as base and thus may lead to premature timeout.
* if we spent non-trivial amount of time invoking callbacks, we may use stale tick number as base of some timeout.

Reviewed By: djwatson

Differential Revision: D13541504

fbshipit-source-id: b7e675bb5a707161f5c7f636d4c2a374a118da83

Summary:
Currently, when cascading, we are unable to use bucket 0. This means that timeouts that are already expired would need to wait another tick before being fired.

A simple example is when we're at tick 0 and scheduling for tick 256, such timeout would go into cascading logic and should fall into bucket 0 of next wheel epoch. However, the existing logic would cascade it to bucket 1.

This diff fixes that, by reordering draining of current bucket and cascading timeouts.

Reviewed By: yfeldblum

Differential Revision: D13541506

fbshipit-source-id: 1284fca18612ae91f96538192bfad75e27cd816c

Summary:
The current implementation may fire timeouts prematurely due to them being put in a bucket that we're about to run. In particular, timeouts that span `WHEEL_SIZE-1` (2.55-2.56s with default interval of 10ms) have very high likelihood of being fired immediately if we have another callback already scheduled.

The issue is that we may use a bucket for the next epoch of wheel before the previous epoch drained it. This diff fixes it by using next unprocessed bucket as a base.

Reviewed By: yfeldblum, djwatson

Differential Revision: D13541502

fbshipit-source-id: 963139e77615750820a63274a1e21929e11184f1

Summary:
Currently, every timeout scheduling will compute the next tick twice:
* when deciding which bucket to use
* when actually scheduling next timeout in `scheduleNextTimeout`

This means that we may end up using a bigger nextTick in `scheduleNextTimeout` (if we were at a boundary of a tick and/or if there was a context switch). This means that if the timeout value is low and we will put it for `nextTick`, then it will end up waiting 2.5s (while we make one round over all slots).

With this change we make sure that the same tick is used.

I could consistently reproduce an issue by running 256 threads that just schedule immediate timeouts all the time.

Reviewed By: yfeldblum

Differential Revision: D13531907

fbshipit-source-id: a152cbed7b89e8426b2c52281b5b6e171e4520ea