Summary: The headers are installed, but we weren't compiling the implementation.

Reviewed By: simpkins

Differential Revision: D13778568

fbshipit-source-id: 4d297b732d1e70bbd69100f13eb68f9477d7f014

Summary: This helps avoid executor re-schedule when Future is ready.

Reviewed By: yfeldblum

Differential Revision: D13805939

fbshipit-source-id: f553c7a581882a7b53b004fd6bbb5087ea5787f8

Summary: Currently, `runOnDestruction` aims to be thread-safe; new callbacks are added to the `onDestructionCallbacks_` list while the associated mutex is held. However, the caller may own the `LoopCallback` and wish to destroy/cancel it before the `EventBase` destructor runs, and this callback cancellation is not thread-safe, since unlinking does not happen under the lock protecting `onDestructionCallbacks_`. The primary motivation of this diff is to make on-destruction callback cancellation thread-safe; in particular, it is safe to cancel an on-destruction callback concurrently with `~EventBase()`.

Reviewed By: spalamarchuk

Differential Revision: D13440552

fbshipit-source-id: 65cee1e361d37647920baaad4490dd26b791315d

Summary: Apply timed reclamation to tagged and untagged lists to avoid accumulating a large amount of unreclaimed memory in use cases with large protectable structures.

Reviewed By: davidtgoldblatt

Differential Revision: D13779937

fbshipit-source-id: e2e14ac5f18c1ee30808116cbc29d21895d9fb1c

Reviewed By: yfeldblum

Differential Revision: D13800383

fbshipit-source-id: 61b988182cb8da6f084b62a0879f0ca917f8ad34

Summary:
Current implementation will loop over bitmap to figure out next tick to schedule. This consumes visible amount of CPU (10% in fibers benchmark, ~4% of Thrift noop load test).

However, this looping is unnecessary, because we already have all information available - what is the earliest pre-existing timeout (expireTick_) and the new one. So we can decide what tick to schedule for by just simple conditional statement.

Reviewed By: vitaut

Differential Revision: D13709523

fbshipit-source-id: b0e3e6301cc2e759b4e8901ba5ff009587516cf5

Summary: Got outdated in D3143931.

Reviewed By: yfeldblum

Differential Revision: D13494612

fbshipit-source-id: e24bfea36896ec04b15fa443348e00f50f75940d

Summary: setCallback_ is an internal API that doesn't provide a guarantee that when the callback is run the Try will be stored inside of the original future. Thus the Try should be moved by the callback instead.

Reviewed By: LeeHowes

Differential Revision: D13793991

fbshipit-source-id: 1e8c4e423b8e1786099cae84bd99ac350c32d937

Summary: make an adapter executor that forwards add to addWithPriority of the underlying executor

Reviewed By: andriigrynenko

Differential Revision: D13788642

fbshipit-source-id: 5b4af43f4a3a3931817a2425890558f811152225

Summary: [Folly] Cut `pushmi` example which uses non-yet-`std` names.

Reviewed By: kirkshoop

Differential Revision: D13777367

fbshipit-source-id: 7ae846e74b622fb0f434220961d35bb243be6868

Summary:
Most of the tests that use this macro, use it to ensure proper behavior of time-related logic (i.e. timeout didn't fire too early/late). Skipping them, simply masks a failure. The underlying utility already takes care of lags due to scheduling, so whenever this check fails - means we have a bug.

In particular, we have 3 tests for HHWheelTimer that are always skipped, because their tolerance is below the expected lag of HHWheelTimer (it always rounds up, so we should expect +1ms always).

Reviewed By: vitaut

Differential Revision: D13746558

fbshipit-source-id: 78f954f52414e640af92e5bb50790135cdd89a92

Summary: was reading coro example and i think a line is missing

Reviewed By: andriigrynenko

Differential Revision: D13788989

fbshipit-source-id: ceb024a36ddd89369ee25f6632fce8d339c489cb

Summary: [Folly] Tweak deletion of `fbstring::operator=` taking convertible-to `char`.

Reviewed By: Orvid

Differential Revision: D13747744

fbshipit-source-id: f254f13a15cb0e72120d1d02f4c8893a788e429a

Summary:
Make sure SCOPE_FAIL works with std::rethrow_exception().

When compiled with older versions of gcc this code would fail due to a gcc
bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258
The gcc bug was fixed in 4.9.4, 5.3, and the 6.0 branch.

Reviewed By: meyering

Differential Revision: D3280778

fbshipit-source-id: 8fe1a9c1dc3ada61c8ebd7318538ae959b29a6b1

Summary:
The other tests are either simple API tests for single-threaded cases, or a
benchmark.

Reviewed By: djwatson

Differential Revision: D13678336

fbshipit-source-id: 5aba91879d756097f42d245b5d318ad7c945dfeb

Summary:
Until C++17 constructor type deduction becomes a thing, we can use this
instead to mimic unique_lock construction without having to specify the type
of the mutex explicitly.

```
auto lck = folly::make_unique_lock(mutex);

// as opposed to

auto lck = std::unique_lock<MutexType>{mutex};
```

Reviewed By: davidtgoldblatt

Differential Revision: D10386999

fbshipit-source-id: 0780a6d1769597a3888305248bcdf93a84c9f9ee

Summary: See F14.md changes.

Reviewed By: nbronson

Differential Revision: D13722323

fbshipit-source-id: 70c68442cad56efc84bb29f0b694a7b71f837cbd

Summary:
This adds support for the Lockable concept for DistributedMutex through a
unique_lock specialization.  There is also a corresponding lock_guard
specialization.  This should cover 95% of usecases very well.  The other 5%
should probably consider using std::unique_lock, std::lock_guard or
folly::Synchronized

Note that std::unique_lock and std::lock_guard can be specialized.  The
standard does not explicitly prevent specializations for these classes as long
as the specializations are dependent on user-defined classes.  This makes it
ok for us to specialize these two interfaces for our folly mutexes.  See the
quoted paragraph below

Section §[namespace.std]

> A program may add a template specialization for any standard library
> template to namespace std only if the declaration depends on a user-defined
> type and the specialization meets the standard library requirements for the
> original template and is not explicitly prohibited.

The generic lockable wrappers that implement the std::unique_lock and
std::lock_guard interfaces are present in
folly/synchronization/detail/ProxyLockable.h.  The specializations of
std::unique_lock and std::lock_guard in namespace std use these
implementations.  This allows us to stick with a simple specialization for our
mutex, which is well-defined per the paragraph above

Reviewed By: djwatson

Differential Revision: D10377227

fbshipit-source-id: 9f2c50ff5732714c83a79752f58c792e6b2a5e88

Summary: The size of the vector is essentially 4, there's no point of allocating it on heap. This improves locality and avoids unnecessary indirection.

Reviewed By: jmswen

Differential Revision: D13709524

fbshipit-source-id: 76c80b835a73ec8f7f5096ae927292571d137596

Summary:
Add test to ThreadPoolTest that LifoSemMPMCQueue::add does not throw when queue is not full.

The test fails before changing LifoSemMPMCQueue::add to use MPMCQueue::writeIfNotFull instead of MPMCQueue::write,and passes after the change.

Reviewed By: djwatson

Differential Revision: D13722155

fbshipit-source-id: 09e296f18eba5c3a78734284b5e409cf006951cc

Summary:
This change ensures that LifoSemMPMCQueue and PriorityLifoSemMPMCQueue do not throw unless the queue is full.

Before this change it was possible for an add operation to throw even when the queue is not full, if a consumer operation is delayed while in progress.

Example:
Queue of size N.
T1: Producer completes N add operations.
T2: Consumer starts a take operation and gets delayed.
T3: Consumer completes N-1 take operations.
T1: Tries an add operation. If using MPMCQueue::write (which returns false) throws even though the queue is not full (has N-1 empty slots). If using MPMCQueue::writeIfNotFull() returns true after waiting for T2's take to complete.

This is somewhat similar to BugD3527722.

Reviewed By: djwatson

Differential Revision: D13701978

fbshipit-source-id: a799353c41d0dc6e673b5fe0ad2a64fd5440fbe8

Summary:
- Use `std::mt19937` instead of `boost::random::mt19937`.
- Use `std::uniform_int_distribution` instead of `boost::uniform_int`.
Pull Request resolved: https://github.com/facebook/folly/pull/1000

Reviewed By: aary

Differential Revision: D13729752

Pulled By: yfeldblum

fbshipit-source-id: 26828c157c458e56ce225af25e2a96890f0633ab

Summary: [Folly] `SingletonRelaxedCountable`, a convenience API around `SingletonRelaxedCounter` for counting instances of a type.

Reviewed By: ovoietsa

Differential Revision: D13686867

fbshipit-source-id: b2f7673e7e88c473337f66901c3e787d35eca6c6

Summary:
- Since GCC 5 and later has `std::atomic_init`, remove the workaround
  present in `Tearable.h` to default initialize atomic variables.
- Default initialization of atomics do not work as you would expect. See
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0883r0.pdf
  for the explanation why.
- To get around the default initialization issue, we just call
  `std::atomic_init` for each element in the array of atomics.
Pull Request resolved: https://github.com/facebook/folly/pull/996

Reviewed By: LeeHowes

Differential Revision: D13648263

Pulled By: yfeldblum

fbshipit-source-id: 6f3c84089f9158bc5c0ad5efac13d49ef69f1770

Summary:
This is mostly a POC. It will probably fail in some cases, but it's better than nothing.
Sample output:
  (gdb) co_bt this
  0x292d70 <zero()>
  0x293f50 <one()>
  0x295050 <two()>
  0x296150 <three()>
  0x297250 <folly::coro::TaskWithExecutor<int>::start() &&::{lambda(folly::Promise<int>, folly::coro::TaskWithExecutor<int>)#1}::operator()(folly::Promise<int>, folly::coro::TaskWithExecutor<int>) const>

Reviewed By: jwiepert

Differential Revision: D13727139

fbshipit-source-id: bff98eb4f5eb2ebd73c880d3b525172782f87511

Summary: Backport `std::bit_cast` from C++20.

Reviewed By: yfeldblum

Differential Revision: D13705428

fbshipit-source-id: a4b284563be67bec3fe4ddb54fed299650458d30

Summary: Adds option to wangle's SSLContextManager to disable renegotiation explicitly and makes folly's AsyncSSLSocket report rejected renegotiations from 1.1.x

Reviewed By: siyengar

Differential Revision: D13633405

fbshipit-source-id: 2b0fc5af4a12795efb52795d64b18b7b6c87e334

Summary: As it says on tin.

Reviewed By: knekritz

Differential Revision: D13144407

fbshipit-source-id: 8fc69f9005ca54c2fb82b501547de2aaa892c1fa

Summary:
setup.py to create folly Cython bindings

Minimum required to get fbthrift to compile in OSS, so only includes executor

Cython requires that source files (pyx and pxd) are in a directory matching the extension name, to provide this a tree of symbolic links is created and the Cython compile happens in that directory.

  - Python3 > 3.6 available?
  - Cython installed?
Pull Request resolved: https://github.com/facebook/folly/pull/992

Reviewed By: simpkins

Differential Revision: D13716102

Pulled By: calebmarchent

fbshipit-source-id: 5fb285b0b43e8b6d1774fa4b6f2525c327cbcc7e

Reviewed By: lewissbaker

Differential Revision: D13706612

fbshipit-source-id: a7c604dbb9216430cc30d63a7fe78530afad585c

Summary:
After count_.store was done it's possible that the thread performing collect observed the value, and then it successfully decremented the counter to 0 and destroyed TLRefCount. The rest of the code in update method then couldn't safely assume that the TLRefCount object is still alive.
This fixes collect to actually wait for update to complete (if we detect that we actually captured the new value written by such update).

Reviewed By: davidtgoldblatt

Differential Revision: D13696608

fbshipit-source-id: bd1a69ea3cc005b90ff481705fdffb83d8a9077a

Summary:
Currently, fibers library has its own class for managing timeouts - TimeoutController. It's optimized for the case when the set of timeouts is fixed and its size is not large. However, it's not efficient when that's not the case (see the benchmark). Since we're starting to use fibers in Thrift, we'll need to make sure that the underlying timeouts management is efficient for unbounded cases.

This kills `TimeoutController` and switches FiberManager to use `HHWheelTimer` from the underlying LoopController (which is in general EventBase).

One important note is that `HHWheelTimer` is **not exact** it rounds up timeouts to the 10ms boundary, so this **will slightly change the behavior**.

The results of FibersBenchmark before & after:

Before:
```
============================================================================
folly/fibers/test/FibersBenchmark.cpp           relative  time/iter  iters/s
============================================================================
FiberManagerCancelledTimeouts_Single_300                    16.34ms    61.18
FiberManagerCancelledTimeouts_Five                          17.54ms    57.00
FiberManagerCancelledTimeouts_TenThousand                  252.06ms     3.97
============================================================================
```

After:
```
============================================================================
folly/fibers/test/FibersBenchmark.cpp           relative  time/iter  iters/s
============================================================================
FiberManagerCancelledTimeouts_Single_300                    22.75ms    43.95
FiberManagerCancelledTimeouts_Five                          21.12ms    47.34
FiberManagerCancelledTimeouts_TenThousand                   19.13ms    52.27
============================================================================
```

This shows that with HHWheelTimer, throughput is unaffected by the number of different values used.

Reviewed By: andriigrynenko

Differential Revision: D13613830

fbshipit-source-id: 7b4662d308a9e1ef232672338a78b79efba46172

Summary:
So it seems that my previous approach doesn't solve the issue completely, we are still seeing these errors, because std::numeric_limits<T>::epsilon() precision is not enough. We can do a different epsilon i.e 1e-6 but it will probably create other problems when values are very big or very small.

I've read about how to do a proper comparison here: https://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/testing_tools/extended_comparison/floating_point/floating_points_comparison_theory.html
but this seems to bee too complicated and slow to introduce relative error comparisons here.

So I decided that we shouldn't do this comparison for floating types at all, because it doesn't make much sense, because we are trying to capture integer overflow with these guards.

Example:
"E0116 06:30:24.439344 3368082 Histogram.h:233] Called: lhs: 3.999999999999005240 rhs:4.000000000000000000 eps: 0.000000000000000222 diff: 0.000000000000994760"

Reviewed By: yfeldblum

Differential Revision: D13693535

fbshipit-source-id: e3e7dafa4517612c63bc8e22b62eeeb053677cb8

Summary:
- Folly no longer guarantees support for GCC 4.9.
- It is only tested with GCC 5.1 or later, so update the `README` to
  reflect that.
Pull Request resolved: https://github.com/facebook/folly/pull/997

Reviewed By: markisaa

Differential Revision: D13648256

Pulled By: yfeldblum

fbshipit-source-id: c694ea0af0c63bd4ec16eb2a8a3e2d95b5801f4d

Summary: Allocate the IOBuf object and the SharedInfo in a single memory allocation

Reviewed By: yfeldblum, simpkins

Differential Revision: D13580880

fbshipit-source-id: cde0eb48c00b9310d0540edb4a9c2d64d6f44a5d

Summary:
- Instead of wrapping a type trait with `_t` use the standard library's
  `_t` type trait variant. This is safe since Folly requires C++14,
  whereas previously the use of `_t` was supported prior to C++14.
Pull Request resolved: https://github.com/facebook/folly/pull/994

Reviewed By: vitaut

Differential Revision: D13634598

Pulled By: yfeldblum

fbshipit-source-id: 09ed9fc1444f507b7422b690b36926cb57616e9e

Summary:
Previously this was just a comment that we documented; but it's easy to check
it directly.

Reviewed By: yfeldblum

Differential Revision: D13678337

fbshipit-source-id: 24990a732a2cc0019e90e294603bb8254a5cbc37

Summary: Adds an accessor for the free function.

Reviewed By: yfeldblum

Differential Revision: D13648280

fbshipit-source-id: ca92054b88b27569d6afec2ed4d1bd68351857cc

Summary: In some cases we want to prefetch the upper bits first.

Reviewed By: philippv, luciang

Differential Revision: D13663518

fbshipit-source-id: c69fe4740fb96f3e9d448410cdf9c4a6edbb6c30

Summary:
Add and assign to options bindings.
Add a isReady to future bindings

Reviewed By: yfeldblum

Differential Revision: D13667465

fbshipit-source-id: 8522ef59d7d262cc13dc9f9940c37b7a0b65870c