Summary:
IntervalRateLimiter was already operating on millisecond
granularity. coarse_steady_clock offers better performance because
it's on millisecond granularity.

Reviewed By: yfeldblum

Differential Revision: D8245042

fbshipit-source-id: 7ce0e347c0498ff2741adc727577c3bb2ce63979

Summary: Iterate only through the threads that have in use entries - v2

Reviewed By: djwatson

Differential Revision: D8143429

fbshipit-source-id: 51098ff8e1fef7aaf9f1c0f2ddbf7ebb579cbeb4

Summary:
[Folly] Cut `FOLLY_IS_TRIVIALLY_COPYABLE` macro, replacing all uses with `folly::is_trivially_copyable`.

And cut `folly::IsTriviallyCopyable` with member-type-detection support, and move `folly::traits_detail::is_trivially_copyable` to `folly::is_trivially_copyable`.

`FOLLY_IS_TRIVIALLY_COPYABLE` and `folly::IsTriviallyCopyable` were there to support gcc < 5.

Reviewed By: Orvid

Differential Revision: D8246972

fbshipit-source-id: 8af9bbdbfac8671a61ebaa200dbfd2426a40d2eb

Summary:
x86_64 chips with SSE >= 4.2 and many aarch64 chips have
CRC32-specific instructions with excellent latency.  This diff switches
the bit mixer applied to untrusted hash functions to use these instructions.
This is a noticeable win for the F14 uses that are CPU front-end bound.

Reviewed By: yfeldblum

Differential Revision: D8245688

fbshipit-source-id: f6a1c1c2a6365201178c653cd5d8c04fbac8d78e

Summary:
Overall plan to modify Future<T>::delayed to complete on the same executor as the input future.

4/n: Remove Future::delayed completely to ensure that all users are on delayedUnsafe so that when we put delayed in with correct behaviour there is no incorrect use.

Reviewed By: marshallcline

Differential Revision: D8223327

fbshipit-source-id: c675d2d51afa2131eee5871afea45f1c6cc65a77

Summary: Minor refactoring of several fbcode/folly/ classes.  Primarily constification, replacing custom code with call to boost, etc.

Reviewed By: yfeldblum

Differential Revision: D8239891

fbshipit-source-id: 14cb109b5deb27f8949b7889d195fcba29e2038c

Summary:
F14 can apply some additional optimizations for trivially
copyable and trivially destructible values in the case that the allocator
doesn't do anything special in its construct and destroy methods.
Previously this was gated based on whether the allocator was exactly
std::allocator, but that causes this optimization to be missed in some
important cases.  This diff extends the checking machinery to test if
there is actually a default construct or destroy method in the allocator
(they are optional) and to test if there is a manual override of the
conservative default check.

Reviewed By: yfeldblum

Differential Revision: D8191437

fbshipit-source-id: c55b8f32427c3f0eff5c8ef42d7b51a57b0cbd1f

Summary:
Core::hasResult() is called in lots of places:

- future.result()
- future.get()
- future.wait()
- future.within()
- future.hasValue()
- future.hasException()
- future.getTry()
- future.raise()
- future.poll()
- promise.setInterruptHandler()
- etc.

This diff improves that function as follows (source: godbolt, with optimization, on both gcc and clang):

- old: 7 instructions w/ 2 conditional jumps + 1 unconditional jump; fastest path is 4 instructions w/ 2 jumps, slowest is 7 instructions w/ 2 jumps
- new: 3 instructions w/ 0 jumps

Small improvement overall, but to a widely used function.

Reviewed By: yfeldblum

Differential Revision: D8231048

fbshipit-source-id: 83a9f5c602475c2ca7066a45635d807596ecf37d

Summary:
- Add class-level description including states & state-transitions
- Add method-level contracts to Core

Reviewed By: yfeldblum

Differential Revision: D7923362

fbshipit-source-id: f7b0f340b6a768c33068547aa4a38acc72ad7088

Summary: We are changing `folly::collectAll` to return `SemiFuture` rather than `Future` and this is needed as an interim step. After all calls to `collectAll` are changed to `collectAllSemiFuture`, we'll be renaming it back to `collectAll`.

Reviewed By: yfeldblum

Differential Revision: D8210974

fbshipit-source-id: e4a7464f4a1c3ede157b8377a4df97d943001f60

Summary:
[Folly] Simplify `folly/test/ExecutorTest.cpp`.

* `auto` is fine.
* `auto` is equivalent to `auto&&` when copy-elision is performed - in the former case, the compiler may use copy-elision to elide materialization of a temporary, whereas in the latter case, the compiler must materialize a temporary, rendering them equivalent..
* `std::addressof` is useful only for unknown types; prefix-`&` is fine for known types which do not overload that operator.

Reviewed By: Orvid

Differential Revision: D8226453

fbshipit-source-id: c987c71d65c01a2d8ca81960f796fcc6100c3484

Summary:
F14MapTest's random test checks afterward that some events
happened, but this is not assured on different platforms.  This diff
inverts the checks so that the loop is continued until all necessary
events have triggered.  Hypothetical failures of the condition checked
by the removed EXPECT_GE checks will be visible after this diff as
test timeouts.

Reviewed By: andreazevedo

Differential Revision: D8226301

fbshipit-source-id: 2ec295b0f5f47e0726cdf1eb64b81c0c23eedae2

Summary:
Container swap is not allowed to fall back to allocation + move
when allocators are not equal, which makes swap undefined in that case.
FOLLY_SAFE_CHECK it.  For zero-size allocators this check will be optimized
away at compile time.

Reviewed By: yfeldblum

Differential Revision: D8209358

fbshipit-source-id: 6555f102c51c97f1e1ecfebd0597c532849184b5

Reviewed By: yfeldblum

Differential Revision: D8208046

fbshipit-source-id: 58ae8a1df7fedd7bb8ec63bcb51c82ec7fb3c9e8

Summary:
Avoid spin-waiting for threads that may be descheduled by making steps that used to require waiting for action by a specific thread wait-free. The changed steps are:
- Allocating and linking the next segment
- Advancing tail to the next segment
- Advancing head to the next segment

For SPSC, the consumer still must wait for the producer to advance tail before it advances head.

Reviewed By: djwatson

Differential Revision: D8124279

fbshipit-source-id: 4dc9b2c1f333a71e7283175e0f9c4ab2eaeb7549

Make Future<T>::delayed complete on correct executor 2/n: Apply codemod future delayed to delayed unsafe

Summary:
Overall plan to modify Future<T>::delayed to complete on the same
executor as the input future.

2/n: Codemod Future<T>::delayed to Future<T> delayedUnsafe. Name-only change, no behaviour.

Reviewed By: yfeldblum

Differential Revision: D8217994

fbshipit-source-id: e20f861c2545f08a177b78e1dba643b267146e94

Summary: We do not want implicit copies of `KeepAlive`, because they may be accidental and they impose an overhead. However, making a copy by calling `folly::getKeepAliveToken(keep_alive.get())` does not look very nice. Also, in case that `keep_alive` is a dummy, it makes an unnecessary call to `Executor::keepAliveAcquire`, which will return false but cannot be inlined usually because it's a virtual function. This diff adds a `copy() const` method which returns a copy of the `KeepAlive` object. It only calls `Executor::keepAliveAcquire` if the original object is not a dummy.

Reviewed By: yfeldblum, andriigrynenko

Differential Revision: D8203839

fbshipit-source-id: bb595d3836405bd84e55c4214ac19127b1e0e42a

Summary:
This diff adds a simple unit test, verifying that construction
of a `KeepAlive` object (either from `Executor*` or move construction)
calls `keepAliveAcquire` and `keepAliveRelease` the correct
number of times.

Reviewed By: elsteveogrande

Differential Revision: D8203944

fbshipit-source-id: 297beeaab99c55d7284ca06edd5e6b9023e27619

Summary:
Somehow gcc49 as used in travis-ci is having a hard time deciding which
constructor to call in `folly/executors/test/ThreadPoolExecutorTest.cpp:721`.
It can't decide between `folly/executors/CPUThreadPoolExecutor.h:69` and
`folly/executors/CPUThreadPoolExecutor.h:83`.
All this diff does is give it a hint about which constructor it should
use.

Reviewed By: yfeldblum

Differential Revision: D8219425

fbshipit-source-id: d92b08efc8bad795ce4a6775efd1e0512aaa6bb5

Summary: [Folly] Cut Futures private invocability helpers, which can be replaced with invoke_result, is_invocable, etc.

Reviewed By: marshallcline

Differential Revision: D8087901

fbshipit-source-id: 17282d77aaff61350d1e7f1b0c363c25db8fb5b1

Summary: [Folly] No longer allow continuations taking non-const lvalue-ref, since that is not really necessary - callers can get all the same results using continuations taking non-const rvalue-ref instead.

Reviewed By: Orvid

Differential Revision: D8166011

fbshipit-source-id: 468d049c6034339f3caf1a82fbc8c755ec2f51e6

Summary:
Overall plan to modify Future<T>::delayed to complete on the same
executor as the input future.

1/n: Adds Future<T>::delayedUnsafe that is identical to Future<T>::delayed
but acts as a codemod target.

Reviewed By: marshallcline

Differential Revision: D8209451

fbshipit-source-id: ee9c1184de2847e142516b315140fcc6d43948c5

Summary:
`libfollylogging_example` is failing to link because it cannot find the
definition of `folly::default_domain`.
This diff adds Hazptr.cpp to the build script, which actually defines
`folly::default_domain`.

Reviewed By: yfeldblum

Differential Revision: D8217299

fbshipit-source-id: 5fb36ef2f160cf45e93c2fc4098d58d384390e5d

Summary:
- Use the hazptr library under folly/synchronization.
  - Use hazptr_obj_base_linked to manage counted links.

Reviewed By: djwatson

Differential Revision: D7674822

fbshipit-source-id: a87ece5dd1c7670677486af59988af8518abaf92

Summary:
CodeMod: `future-then-continuation-lvalue-ref`.

```
buck run mode/opt foundation/clangr:clangr_coordinator -- run foundation/clang/codemods:future-then-continuation-lvalue-ref --dev -p 7 --num-workers=200
```

There is no need to support continuations taking non-const lvalue-ref params; callers can get exactly the same semantics with non-const rvalue-ref params instead. Thsi codemod preserves semantics. Many of these cases could do just as well taking by value, but this codemod preserves semantics.

Reviewed By: Orvid

Differential Revision: D8166008

fbshipit-source-id: 84b635cccce24b6485ffb5b24b98f10422b9a517

Summary: Original commit changeset: adcd387e237d

Reviewed By: mzlee

Differential Revision: D8204982

fbshipit-source-id: 2c66f58ccf41dc70f55b3ecffc6e197c23c4f959

Summary: Fix typos

Reviewed By: Tingzhe

Differential Revision: D8160938

fbshipit-source-id: f4eaf496a33b7d2b6266a8424850640028660331

Summary:
As title.  These methods look like they never protected observers_ list, and relied on
the user not calling addObserver or removeObserver concurrently.  I don't see any downsides
to taking a write lock here, these methods aren't called often.

Reviewed By: davidtgoldblatt

Differential Revision: D8187184

fbshipit-source-id: dd20b809e851cc14a05aca3bc9722e0a9236665f

Summary: Causing perf issues.  Users must add explicitly to tests or other use cases.

Differential Revision: D8162835

fbshipit-source-id: 7095064209ced870768552307675dc1ebbf68bdc

Summary:
Add correct memory barrier to thread timeout / add path.

This seems like the fastest way to maintain safety here.  We could use
a read-biased rw lock instead, but that would mean taking a heavy memory
barrier in add() if we do have to add a thread.

Reviewed By: davidtgoldblatt

Differential Revision: D8161950

fbshipit-source-id: af2bd3a601ced9bb04a8206696e7a998c75f6369

Summary: Future::delayed could complete on Future::sleep's executor. Ensure instead that it completes on the future's executor.

Reviewed By: yfeldblum

Differential Revision: D8052038

fbshipit-source-id: adcd387e237dbd724d5f9deb5c80d1418987482d

Summary: Make onTimeout call thenError which maintains the executor rather than onError which does not.

Reviewed By: yfeldblum

Differential Revision: D8051906

fbshipit-source-id: 41ca5f657a441ff8eaacdfab6d4cfb45d5e5f0c2

Summary: This enables using Executor adaptors (e.g. SerialExecutor) with futures.

Reviewed By: yfeldblum

Differential Revision: D8198893

fbshipit-source-id: 48c59b618bd2bbad4277b7f0b0f0b19347266813

Summary:
Futures documentation was drifting out of date. The documentation index also had broken links to Futures and a core readme.

This change adds basic futures documentation in the docs tree and removed the README.md in the futures tree.

Reviewed By: marshallcline

Differential Revision: D7937360

fbshipit-source-id: 120610cca21db5a8b38199a5098551f10bb85251

Consistency with folly::SemiFuture continuations 5/n: make deferError use the same exception unpacking machinery as thenError

Summary:
Step 5 in adding full set of r-value-qualified unambiguous continuation methods to folly::Future for consistency with folly::SemiFuture.
 * Back point explicit exceptions election to deferError.

Reviewed By: marshallcline

Differential Revision: D8124828

fbshipit-source-id: 123b1cf460d2df4c8f359eff7329d34fbd8e0a9b

Summary: Add cleanup benchmark

Reviewed By: magedm

Differential Revision: D8162617

fbshipit-source-id: 5ef729913db889f999c8bb051c4291e748854000

Summary: Add a try_peek() member function valid only if SingleConsumer==true that returns folly::Optional<const T*> which (if has_value() is true) contains a pointer to the first element in the queue.

Reviewed By: djwatson

Differential Revision: D7969290

fbshipit-source-id: 3e15138f6c6523adce4da4cd99b74e0a83cd24d7

Summary:
Use folly::test::Barrier in benchmark instead of spin-waiting.  Benchmarks are more consistent now,
and perf output is useful instead of showing a bunch of spinning.

Also remove the DSched stuff from bench(), we don't want to benchmark DSched.

Reviewed By: davidtgoldblatt

Differential Revision: D8162600

fbshipit-source-id: 52a1218e7fc2b87f0926dbc29c13bf0c9478e804

Summary: Split barrier to separate file so it can be used in other tests.

Reviewed By: magedm

Differential Revision: D8162586

fbshipit-source-id: c3a239fe6fdb3f895557e7b93a5a960b9e871f0c

Summary:
[Folly] Avoid errnoeous deprecation warning in `F14BasicSet`.

The deprecation warning is emitted for instantiations like `F14FastSet<std::string>`.

The warning is triggered by looking for move-constructibility of the mapped type for maps or `void` for sets, but `void` is not move-constructible. There are a variety of techniques to solve this, and the smallest change is to use `lift_unit_t` in the right place. `Unit` is move-constructible where `void` is not.

Reviewed By: nbronson

Differential Revision: D8178045

fbshipit-source-id: 1ca06e84b4ed7acd415901afcbe80663513063ea