Summary:
[Folly] Make `co_current_executor` look like `nullptr`, `std::nullopt`, `std::in_place`.

* Use a `co_` prefix to indicate that it is offers a useful result when awaited.
* Offer a well-named value with a well-named type or type alias.
  * There is the `nullptr` value and `std::nullptr_t` type or type alias.
  * There is the `std::nullopt` value and the `std::nullopt_t` type or type alias.
  * There is the `std::in_place` value and the `std::in_place_t` type or type alias.

Reviewed By: andriigrynenko, lewissbaker

Differential Revision: D13561713

fbshipit-source-id: 835da086e7165d37a952a1f169318cb566401d12

Summary: Everything has been migrated over to the NetworkSocket overload.

Reviewed By: yfeldblum

Differential Revision: D13566609

fbshipit-source-id: 920505a9e91f1acc5810949049880ed07294621b

Summary:
In the case when an explicit capacity is specified (via reserve()
or an initial capacity) we can save memory by using a bucket_count()
off of the normal geometric sequence.  This is beneficial for sizes
<= Chunk::kCapacity for all policies, and for F14Vector tables with
any size.  In the multi-chunk F14Vector case this will save about
40%*size()*sizeof(value_type) when reserve() is used (such as during
Thrift deserialization).  The single-chunk savings are potentially larger.
The changes do not affect the lookup path and should be a tiny perf win in
the non-growing insert case.  Exact sizing is only attempted on reserve()
or rehash() when the requested capacity is >= 9/8 or <= 7/8 of the current
bucket_count(), so it won't trigger O(n^2) behavior even if misused.

Reviewed By: yfeldblum

Differential Revision: D12848355

fbshipit-source-id: 4f70b4dabf626142cfe370e5b1db581af1a1103f

Summary: Add test for recursive destruction.

Reviewed By: djwatson

Differential Revision: D13476864

fbshipit-source-id: 513f39f44ad2f0d338d10066b2e337902db32e00

Summary: Enable destruction order guarantee, i.e., destructors for all key and value instances will complete before the completion of the destructor of the associated ConcurrentHashMap instance.

Reviewed By: davidtgoldblatt

Differential Revision: D13440153

fbshipit-source-id: 21dce09fa5ece00eaa9caf7a37b5a64be3319d5e

Summary:
Prevent deadlock on tagged retired lists within calls to `do_reclamation()` that call `cleanup_batch_tag()`.

Changes:
- Make locking the tagged list reentrant.
- Eliminate sharding of tagged lists to prevent deadlock between concurrent calls to `do_reclamation()` on different shards that call `cleanup_batch_tag` on the other shard.
- Expose the list of unprotected objects being reclaimed in `do_reclamation()` of the tagged list so that calls to `cleanup_batch_tag()` don't miss objects with a matching tag.
- Refactor of commonalities between calls to `retire()` in `hazptr_obj_base` and `hazptr_obj_base_linked` into `hazptr_obj::push_obj()`.
- Fixed release of tagged list lock to use CAS in a loop instead of store, since concurrent lock-free pushes are possible.

Reviewed By: davidtgoldblatt

Differential Revision: D13439983

fbshipit-source-id: 5cea585c577a64ea8b43a1827522335a18b9a933

Summary:
[Folly] `test_once`, a way to check whether any call to `call_once` with a given `once_flag` has succeeded.

One example of use might be for exception-safety guarding object destruction when object construction is guarded by the `once_flag`, and when the user is interested in conserving per-object memory and wishes to avoid the extra 8-byte overhead of `std::optional`.

```lang=c++
template <typename T>
struct Lazy {
  folly::aligned_storage_for_t<T> storage;
  folly::once_flag once;

  ~Lazy() {
    if (folly::test_once(once)) {
      reinterpret_cast<T&>(storage).~T();
    }
  }

  template <typename... A>
  T& construct_or_fetch(A&&... a) {
    folly::call_once(once, [&] { new (&storage) T(std::forward<A>(a)...); });
    return reinterpret_cast<T&>(storage);
  }
};
```

Reviewed By: ovoietsa

Differential Revision: D13561365

fbshipit-source-id: 8376c154002f1546f099903c4dc6be94dd2def8e

Summary:
Previously the debug-build randomization of F14 iteration order
was applied only to F14ValueMap/Set, F14NodeMap/Set, and F14FastMap/Set
that uses the value storage strategy.  This extends the behavior to
F14FastMap/Set that use the vector storage strategy, which are those
instances where sizeof(value_type) >= 24.

F14FastMap/Set using the vector storage strategy must move items
to randomize, so this reordering will also expose cases that assume
reference or iterator stability across multiple inserts without a call
to .reserve().

Reviewed By: yfeldblum

Differential Revision: D13305818

fbshipit-source-id: 178a1f7b707998728a0451af34269e735bf063f3

Summary: Needed to get a rough sense of its expense to know when it would be worth collecting in contention events.

Reviewed By: prateek1404

Differential Revision: D13544220

fbshipit-source-id: 6a4c00d84d997c6fbe5dfb0e0cdb9bfbbe97a8a0

Summary:
Add the `singleton_thread_local_test` companion shared library to CMake config
and enable these only when folly is compiled with `-fPIC`. This should fix
Travis build.

Reviewed By: yfeldblum

Differential Revision: D13542693

fbshipit-source-id: 2372da298cc69c2e7e491fbde681fe90d8879d47

Summary:
[Folly] `folly::coro::co_invoke`, both generalizing and constraining `folly::coro::lambda` and modeling on `std::invoke`.

Constrained only to work on callables which return `Task<_>` in order to be sure that `invoke_result_t<F, A...>` is the same as the type of `co_await <expr>` where `expr` has type `invoke_result_t<F, A...>`. We know that this constraint holds for `Task<_>`. The alternative is to make it work for all types and use `decltype(auto)` as the return type.

Reviewed By: andriigrynenko

Differential Revision: D13523334

fbshipit-source-id: 9af220dd45d6b9f6676c5ef49ba2e01395babd72

Summary: Found while testing with BufferedDeterministicAtomic.

Reviewed By: djwatson

Differential Revision: D13509000

fbshipit-source-id: ec1cef0afc888136db3ccda8dff99bc0a45f6bff

Summary:
Make code for futex[Wait/Wake]Impl for DeterministicAtomic templated, rename to deterministicFutex[Wait/Wake]Impl, and move to DeterministicSchedule.h so that it can be shared by BufferedDeterministicAtomic.

Point the futex[Wait/Wake]Impl for DeterministicAtomic at deterministicFutex[Wait/Wake]Impl<DeterministicAtomic>.

Create new futex[Wait/Wake]Impl for BufferedDeterministicAtomic using deterministicFutex[Wait/Wake]Impl<BufferedDeterministicAtomic>

Reviewed By: djwatson

Differential Revision: D13519817

fbshipit-source-id: c792ea9dcd6287236bc772e9aa9662277cc9e642

Summary: Replace new/delete[] with std::unique_ptr

Reviewed By: yfeldblum

Differential Revision: D13525009

fbshipit-source-id: 8497329e2881f1cfd6fe7ca5c4ae432c3071faec

Summary: The file descriptor overload will be going away.

Reviewed By: yfeldblum

Differential Revision: D13508239

fbshipit-source-id: 3fce90d98e9252881cb9ed0030fba558d89470af

Reviewed By: yfeldblum

Differential Revision: D13515209

fbshipit-source-id: 6d4688242a586b6e5558c62c1c6f3bb7c6595dfb

Summary: We should never end up doing compare_exchange_weak with oldVal==0, because that may result in increment/decrement from 0.

Reviewed By: yfeldblum

Differential Revision: D13514210

fbshipit-source-id: 0ccffe5d9525389ba02208f3bf37ce14acb9f28e

Summary: coro::Task can be always converted to a lazy SemiFuture. This can be very useful when converting existing futures code to coroutines.

Reviewed By: yfeldblum

Differential Revision: D13502414

fbshipit-source-id: 2e3971217086c762f3f831ef19d0d88b621b7c80

Summary: This can allow converting asynchronous APIs that require an Executor to lazy SemiFuture.

Reviewed By: yfeldblum

Differential Revision: D13502409

fbshipit-source-id: 8c824f314d83f3ab208e7b384c9e535cf40210f1

Summary: This will probably break things.

Reviewed By: yfeldblum

Differential Revision: D13461653

fbshipit-source-id: bd678ad9ac810bfec7be9411d290071358c66781

Summary:
[Folly] Change Synchronized::copy copy-assignment overload: rename to `copy_into`, and take ref v.s. ptr.

(Note: this ignores all push blocking failures!)

Reviewed By: aary

Differential Revision: D13475878

fbshipit-source-id: 4923a0cc73359853357dba60c6e4be654e92ce82

Summary:
[Folly] "Upgrade" wording in `Synchronized`.

(Note: this ignores all push blocking failures!)

Reviewed By: aary

Differential Revision: D13484147

fbshipit-source-id: 5ccaac2de5e03986885000869a862d2a37ab5751

Summary:
The behavior of not allowing write locks on const methods is inconsistent, as
there is no way of determining the semantics of the protected object.  In
particular there are two types of classes that come into mind here

- Pointer and reference like classes.  These can be const, but the underlying
  data item need not be const.  Here it should be perfectly resaonable to
  allow users to acquire a write lock on a const Synchronized<> object
- Types with mutable members.  These can be write locked even when const, this
  behavior is probably okay.

On the other hand the previous motivation of this diff - inconsistency with
upgrade locks is being removed.  They will no longer expose non-const access

Reviewed By: yfeldblum

Differential Revision: D13478631

fbshipit-source-id: 652a08c61abf35c3eadc45cedc5d300fbef83a6b

Summary: Introduce a coro::lambda helper which makes it safe to create coroutine lambdas with captures.

Reviewed By: lewissbaker

Differential Revision: D13473068

fbshipit-source-id: a1177b4d57715b10fc4398fa6626ee105a8a43ce

Summary: The fd overload is going to be removed.

Reviewed By: yfeldblum

Differential Revision: D13478000

fbshipit-source-id: d45c5d7c0dbcbde31976ff5dc48d1abc97d5a743

Summary: It's dead.

Reviewed By: yfeldblum

Differential Revision: D13477847

fbshipit-source-id: 9ba568fe7070b337646e89790339dc6c35d0b86f

Summary:
This is a ReadMostlyMainPtr variant that allows racy accesses. By making the
write-side slower, the read side can avoid any contended shared accesses or
RMWs.

Reviewed By: djwatson

Differential Revision: D13413105

fbshipit-source-id: f03c7ad58be72b63549b145ed6f41c51563831d1

Summary:
onError is to be phased out because:
 * It is weakly typed
 * (most seriously) It loses the executor and so terminates a via chain silently causing subsequent work to run in the wrong place

onError is replaced with thenError which fixes both problems.

This diff merely deprecates it to allow for a gentle phase out.

Reviewed By: yfeldblum

Differential Revision: D13418290

fbshipit-source-id: a0c5e65a97ed41de18d85ceab258417355a43139

Summary: [Folly] Extract `FunctionTraitsSharedProxy`, deduplicating four nearly identical implementations.

Differential Revision: D13461506

fbshipit-source-id: 2927dbe1629024cf778301c509b82711940a8099

Summary: No longer needed

Reviewed By: djwatson

Differential Revision: D13456759

fbshipit-source-id: ea08992d3bd4babbdcf326b0c01f64cd1184784f

Summary:
Clarify the [last section](https://github.com/facebook/folly#ubuntu-1604-lts) of the Ubuntu build instructions about where commands need to be run from and how to invoke `make install`.

Fixes #847.
Pull Request resolved: https://github.com/facebook/folly/pull/984

Reviewed By: Orvid

Differential Revision: D13406491

Pulled By: yfeldblum

fbshipit-source-id: d04121812d0d7394000ea6116745c236db67aa23

Summary: [Folly] `aligned_storage_for`, `aligned_storage_for_t`.

Reviewed By: aary

Differential Revision: D13448822

fbshipit-source-id: 59a09951e0ff75f8b0aeb201a5c1eb28850ea91d

Summary: It's dead... Hopefully...

Reviewed By: yfeldblum

Differential Revision: D13418381

fbshipit-source-id: 1d05aad80342d4f048ae37e90e9fc13d31676ddd

Reviewed By: mzlee

Differential Revision: D13425495

fbshipit-source-id: 9955ae6d59b0604f1e106fef0f0fccca1093e5f4

Summary: l-value Future::onError was deprecated but not deleted. This diff makes that final cleanup.

Reviewed By: Orvid

Differential Revision: D13419719

fbshipit-source-id: d763b75ab3351811f35ad880291426c153aefda9

Summary: This allows avoiding extra executor/queueing operations if caller knows that task can be safely run inline.

Reviewed By: yfeldblum

Differential Revision: D13404703

fbshipit-source-id: 4aa71e59b48572671e8031ee7ea4dcd4e3a6138b

Summary:
There could be cases that user want to record some of their own metrics during benchmark. This diff add another kinds of macro BENCHMARK_COUNTERS to make it happen, see Test plan for an example.

One problem is that it would be hard to output the result on the fly. As it needs to run all benchmarks first to know which customized counter are used, then it can output the proper column headers.

Reviewed By: yfeldblum

Differential Revision: D9874668

fbshipit-source-id: 2004bb4484e54c1edd65763d1727486c6905d884

Summary:
When BufferCallback::onEgressBuffered() is called, applications usually want to
know how many bytes were buffered so that can take actions (such as avoiding
that connection, failing fast, etc).
This diff adds getTotalPendingBytes() to AsyncTransport to allow applications
to easily query how many bytes were actually buffered.

Reviewed By: spalamarchuk

Differential Revision: D13252677

fbshipit-source-id: 8ec203f6764e00f52d471321afb549376397eb84

Summary: There is a bug in ElfFile using strncat which could cause buffer overflows when a previous file open failed. strncat only limits based on the src length, and so if strlen(dest) > 0 this could have overflowed.

Reviewed By: anakryiko

Differential Revision: D13398108

fbshipit-source-id: 793c35884f1e639f36758f36046158858fd5976a

Summary:
The common use case for token buckets to implement resource usage throttling/smoothing also implies that callers need to either implement their own backoff+retry mechanism. The simple exponential backoff approach is prone to starvation and over-throttling (under-utilized resource). Many cases will simply be okay with being told at what point in future their allocations can be met effectively doing the starvation free FIFO scheduling for them. Added a consumeWithBorrow API to enable this behavior.

Added checks in existing API to account for the possibility of the internal clock of the bucket being 'in future' wrt to the 'now' argument passed in the call.

Also added an API to be able to return previously allocated tokens effectively moving the clock back on the bucket. This is largely for completeness and there isn't an immediate use case in mind for this.

Reviewed By: yfeldblum, usumeet

Differential Revision: D13166472

fbshipit-source-id: 4d6f93eedcc75eb07c1250026e57806c96974c96