Summary:
This method ensures the singleton exists with less overhead than
calling `try_get` or `try_get_fast`.

Reviewed By: yfeldblum

Differential Revision: D8020292

fbshipit-source-id: 470ebea9fdb07e46a469c820f9149d6fc5af5d2f

Summary:
There is a race with stop() and timeouts.  stop() may race with a thread timeout, and then block indefinitely on
joinStoppedThreads(), waiting to join the already joined timed-out thread.

To fix, just put everything behind a write lock, simplifying the code at the same time.

Reviewed By: davidtgoldblatt

Differential Revision: D7971779

fbshipit-source-id: eb4a898ca266ddda0f95033950ac041d1cc812ba

Summary:
A lot of functions in AsyncUDPSocket just use a CHECK for fd_ and fail
hard if ths socket hasn't bound to a fd. This adds an API for user to actually
find out if socket has bound without crash.

(Note: this ignores all push blocking failures!)

Reviewed By: siyengar

Differential Revision: D8026035

fbshipit-source-id: fc7bf9c1d6d7f045cd4dba94e3278d20d80de887

Summary:
`folly/test/DynamicTest.cpp` contained a duplicate definition of
`dynamic::print_as_pseudo_json()`.  This caused link errors due if this test
was linked against `json.cpp`.

Part of the problem here is that the `//folly:dynamic` library is somewhat of
a lie: the `dynamic::print_as_pseudo_json()` method is provided by the
`//folly:json` library rather than by `//folly:dynamic`.  This violates
assumptions made by autodeps.  Ultimately the right thing to do might be to
combine `//folly:json` and `//folly:dynamic` into a single rule.

Reviewed By: yangchi

Differential Revision: D8020841

fbshipit-source-id: e563611309c122680a5fc69c3f0da1ad5d4337b0

Fix "multiple definition of 'folly::dynamic::print_as_pseudo_json(std::ostream&) const'" linker error

Summary: Fix "multiple definition of 'folly::dynamic::print_as_pseudo_json(std::ostream&) const'" linker error

Reviewed By: yfeldblum

Differential Revision: D8016705

fbshipit-source-id: 7ef8306852afd8e765f22e657f44fbe67c66f6f5

Summary:
constexpr_clamp_cast<> provides sane numeric conversions from float point numbers to
integral numbers, and between different types of integral numbers.

When doing clamp_cast<DstT>(value), if `value` is in valid range of DstT, it will give correct result in DstT, equal to `value`.

If `value` is outside the representable range of DstT, it will be clamped to MAX or MIN in DstT.

Float NaNs are converted to 0 in integral type.

For comparison, static_cast<> will return garbage results when SrcT is float point number and it's outside DstT valid range. This is because float-cast-overflow is undefined behavior.

Reviewed By: yfeldblum

Differential Revision: D7716736

fbshipit-source-id: 5899e4b20cdd997d0c7b121ddaababbc8c748301

Summary: As per title.

Reviewed By: yfeldblum

Differential Revision: D8014022

fbshipit-source-id: df24a839804e9bb6c063994adbbde3544535b66c

Summary: [Folly] Use `throw_exception` in `folly/futures/`, replacing the one-off throw functions.

Reviewed By: Orvid

Differential Revision: D7965947

fbshipit-source-id: ed5855aaccf4aa07ecb40489db9fa92090df9016

Summary: [Folly] Let `Future` handle throwing `FutureNotReady`, since it is logically the thing that knows about specific exceptions in its contract.

Reviewed By: LeeHowes

Differential Revision: D7964855

fbshipit-source-id: 49f3220a6a41ebe87f577814c0940e00497092c0

Summary:
Update the folly::Init code to define a `--logging` command line flag, and call
`folly::initLoggingOrDie()` with the value of this command line during
initialization.

This is similar to the existing code that initializes the glog library.
(Programs can use both glog and folly logging together in the same program, and
I expect that many programs will do so as parts get converted to folly::logging
and parts remain using glog.)

Reviewed By: yfeldblum

Differential Revision: D7827344

fbshipit-source-id: 8aa239fbad43bc0b551cbe40cad7b92fa97fcdde

Summary: Currently, when we add or delete a `RequestData` instance to `RequestContext` for the first time, we do not call the `RequestData`'s `onSet` or `onUnset` callback. This means if the `RequestData` is doing tracking-related work, it may miss the beginning or the request until the first switch of `RequestContext` has happend, and in the end as well. This Diff fixes the issue by calling `onSet` and `onUnset` when adding or deleting.

Reviewed By: anakryiko

Differential Revision: D7978623

fbshipit-source-id: a524286371f890598bc773e957ef609e90086cea

Summary:
std::lock_guard has a better performance than std::unique_lock in scoped-lock.
Closes https://github.com/facebook/folly/pull/840

Reviewed By: djwatson

Differential Revision: D7888672

Pulled By: yfeldblum

fbshipit-source-id: 391082aa79ada67a3906e828d68f8cc2a29bf22c

Summary:
Update AsyncFileWriter to use pthread_atfork() to stop the I/O thread around a
fork() operation.  Both the parent and child restart the I/O thread after the
fork.  Messages that were queued up at the time of the fork are logged in the
parent process after the fork occurs.

Previously after a fork() the child process would not have an I/O thread
running at all, so any messages sent to this handler would not actually be
written.  This also triggered some ASAN warnings which I did not fully track
down.  In the child process ASAN claimed that the exit handlers were run twice:
from both the main thread and the I/O thread, which is surprising since the I/O
thread should not run in the child process at all.

Reviewed By: mnv104

Differential Revision: D7946725

fbshipit-source-id: e4ad398f7bb334882c5c0b2afacc30c27bf3f6e4

Summary:
fix #839
Closes https://github.com/facebook/folly/pull/846

Reviewed By: yfeldblum

Differential Revision: D7987128

Pulled By: Orvid

fbshipit-source-id: 626ed1724f3df5fecc83413574cfd72f1f0b1fa1

Summary:
* Relax some loads in BufferedStat
* Cache which cpu local buffer to use, similar to SharedMutex

Reviewed By: djwatson

Differential Revision: D7986764

fbshipit-source-id: 581266abc60e3f23f24181264da163baee9fce3f

Summary: [Folly] Use `throw_exception` in `Expected`, replacing the one-off throwing functions and outlining `throw` statements.

Reviewed By: Orvid

Differential Revision: D7985812

fbshipit-source-id: 396b92d1ec40c909c9c37dd7f7d9ed94b2bcf709

Summary: [Folly] Use `throw_exception` in `Try`, replacing the one-off throwing functions.

Reviewed By: Orvid

Differential Revision: D7984674

fbshipit-source-id: 3996e09fd8a7446fbb53760f1ce30a66cb7c13e9

Summary:
[Folly] Let `Pomise` handle setting `BrokenPromise` in its dtor, since it is logically always the thing that invokes `setResult`, rather than having `Core` do it.

This splits up the various responsibilities a little better.

Reviewed By: marshallcline

Differential Revision: D7964264

fbshipit-source-id: a4871fd1a83a0a54d4a6c91fcb74c6df5aa592ba

Summary: Drop this expensive include and just implement the operators.

Reviewed By: yfeldblum

Differential Revision: D7803316

fbshipit-source-id: 969fef54204cf3caa09d67e05be61c3c9a14b67e

Summary: MSVC 2017 Update 7 has issues with expanding empty parameter packs in certain situations.

Reviewed By: yfeldblum

Differential Revision: D7983735

fbshipit-source-id: d90c01a36885b94269b3dbc260142abd6556102d

Summary:
MSVC 15.7 (VS 2017 Update 7) was released a couple days ago, and includes a bug that's breaking Folly. Temporarily work around it.
A point release should be out soon(ish) to resolve the issue: https://developercommunity.visualstudio.com/content/problem/246602/157-fails-with-folly.html
There is still another issue in 15.7 that needs to be worked around, which will happen in a separate diff.

Reviewed By: yfeldblum

Differential Revision: D7937972

fbshipit-source-id: 4a2bc4ae0ea7165c45d100ad0a29409b60a0287a

Summary:
This diff fixes the move constructor form that takes an explicit
allocator for F14VectorMap and F14VectorSet (which may also include
F14FastMap and F14FastSet depending on the value_type).  It also includes
test coverage for exception safety, which did not reveal any problems.

Reviewed By: yfeldblum

Differential Revision: D7981324

fbshipit-source-id: f4ca39aa2654d75289b554a9081621b2a3a6c136

Summary: InitThreadFactory allows running initialization function on newly created threads. This is useful to do preconditioning work on the threads before putting them to use.

Differential Revision: D7947389

fbshipit-source-id: 6a161c887def3862b47473155516c03ba3f10e8b

Summary:
Internal memory fragmentation is responsible for a non-trivial
amount of the memory footprint of a dynamically-allocated hash table.
This diff adds an API visitAllocationClasses that allows the caller to
count exactly how many dynamic allocations were performed and of what
size, so that they can accurately account for overheads not included in
getAllocatedMemorySize's simple sum of the underlying malloc requests.

This diff also exposes F14Table's reset() via F14 maps and sets, which
was an unintentional omission.

Reviewed By: WillerZ

Differential Revision: D7894385

fbshipit-source-id: 2d7cadd3806e3f38a9e38cb94c90492a9965ff47

Summary:
The first allows disabling CMake's google test integration, as it doesn't play nice with the Visual Studio IDE itself.
The second allows setting the version of C++ to use when compiling with MSVC.

Reviewed By: yfeldblum

Differential Revision: D7976567

fbshipit-source-id: e6fe3cc28a23334d69e8cd18f633afab2efecd59

Summary:
Previously the alignment of small_vector did not take into account the alignment of the value_type. Since the value_type is stored directly internally, this is problematic.

This change does increase the sizeof small_vector in a couple cases, but I don't think the previous size was legitimate as sizeof(small_vector<value_type>) was not an even multiple of alignof(value_type).

Reviewed By: yfeldblum

Differential Revision: D7969483

fbshipit-source-id: 968c78bf03d7c0ddfe1338754f12f97be8d0f771

Summary: Start with the easy one.

Reviewed By: yfeldblum

Differential Revision: D7957655

fbshipit-source-id: 0c2227402673306e1e6ba3f463b1a93db2582b07

Summary: socketConnect() is not invoked if we have TFO enabled. Need to explicitly disable it once new socket is created, and noTransparentTls flag is set.

Reviewed By: djwatson

Differential Revision: D7945457

fbshipit-source-id: 739b7ae5bc146b50255254e644fba2618147c4f4

Summary:
Enforce two aspects of folly::futures::Core<T>:

- that it is heap-constructed (prevent clients from constructing it other than via `new`)
- that it cannot be deleted early (prevent clients from explicitly deleting it)

Reviewed By: yfeldblum

Differential Revision: D7900761

fbshipit-source-id: c1c5a149e3d96c4cea04c17909c2ffd42383973e

Summary: It was spamming the MSVC build log with warnings.

Reviewed By: magedm

Differential Revision: D7954677

fbshipit-source-id: 1f2d1163483518382543aacb7e8fbc17e291e650

Summary:
clang whines about these to varying degrees. They seem like
braindead fixes.

Reviewed By: yfeldblum

Differential Revision: D7918701

fbshipit-source-id: a5aae179c2df89ef52148a500e95cd1cd25a1f0b

Summary:
There is a subtle race between thread destruction and task addition (ensureActiveThreads).

For an executor with a single thread, the race would be:
threadid
1 cpu thread returns from try_take_for by timing out.
2 someone from a different thread calls add()
2 add() finds lifosem empty, calls ensureActiveThreads
2 ensureActiveThreads grabs the lock, finds active=1, total=1, returns doing nothing, assuming thread is still running.
1 cpu thread decrements activeThreads_ to 0 in taskShouldStop.

There are now *no* threads running until the next call to add(), and one task waiting.

Fix: Grab lock in taskShouldStop (like the documentation says we should be doing).  Also double check that there are no currently pending tasks.

This probably only affects pools with size of 1, otherwise we would have added a second thread and there may temporarily be one fewer threads running.

Reviewed By: davidtgoldblatt

Differential Revision: D7943241

fbshipit-source-id: 502e5809ccf4ecca85205c14c4d97b508897de9b

Summary:
SerialExecutor used to have public constructors and could be
constructed on the heap or on the stack. In order to be able
to reference the shared stater later from the parent executor,
the task queue was implemented in a separate class, of which
the SerialExecutor would create one, managed by a `shared_ptr`.

With the recent move towards `folly::Executor::KeepAlive`, the
SerialExecutor itself always has to be constructed on the heap
(hence no public constructor anymore but factory functions).
However, that means that we can embed the task queue implementation
in SerialExecutor, using `KeepAlive` objects to access it from
the parent executor.

This change simplifies the implementation of SerialExecutor and
reduces the number of heap objects and thus memory allocations.

Reviewed By: andriigrynenko

Differential Revision: D7927260

fbshipit-source-id: d3b6a2376bfdf512a946f2f45c730ed68176a441

Summary: This turned out to only be useful in tests. Clean up the tests and get rid of it

Reviewed By: yfeldblum

Differential Revision: D7907221

fbshipit-source-id: f5e0263c1426e1af97c190e6b2bd47d7db37d403

Summary: When cleaning up the interface with r-value qualification for SemiFuture it seems we missed deferError.

Reviewed By: yfeldblum

Differential Revision: D7942259

fbshipit-source-id: c0cf05eb2b6357e6f6eb3fab6aef87ec6416caf7

Reviewed By: saifhhasan

Differential Revision: D7943135

fbshipit-source-id: 6b66b7b2ea6343b99ec113febca991eb840b1860

Summary: gcc-5.x does not allow brace elision in these std::array initializer lists.

Reviewed By: yfeldblum, mnv104

Differential Revision: D7923970

fbshipit-source-id: 807f2e0d376c9ac4f4f6988fb811590531b6334d

Summary:
Running the xlog test binary stand-alone revealed a bug that
was otherwise masked when running with buck test. The bug was that
2 tests ended up depending on the log-level associated with a default
category and would thus fail since the tests did not clean up
the log-level setting associated with those categories.
Attached diff fixes the issue by restoring the category's log-level in
a scope exit block.

Reviewed By: simpkins

Differential Revision: D7922086

fbshipit-source-id: 9d8ed917633ae214dc81075fbd38275160e64376

Summary: [Folly] Simpler SFINAE in variadic `F14BasicSet::emplaceItem`, without using `std::tuple_element_t` unsafely when `sizeof...(Args) == 0`.

Reviewed By: shixiao

Differential Revision: D7920929

fbshipit-source-id: d74d5b36ac683f72e21d83294aa890f49194280d

Summary:
Check if the compiler supports -Winconsistent-missing-override before trying to
disable this warning.

It looks like gcc wouldn't actually fail the build if
`-Wno-inconsistent-missing-override` was specified but was not supported.
However, if the build failed due to other compile errors the error messages
about this flag would make it confusing to identify the actual build failure
reason.

Closes issue #836.

Reviewed By: yfeldblum

Differential Revision: D7920577

fbshipit-source-id: 322444a9df3f4f36bb5420f0720c1e433c2856b7