Summary: getRawBytesReceived and getRawBytesWritten should be used instead.

Reviewed By: mzlee

Differential Revision: D2708684

fb-gh-sync-id: 2de87dc2b8c3466f94293a3d7df89fc5fce3a00f

Summary:
In rare cases, it is required to run code **in the child process**, before it calls `exec()` because you need to change the state of the process **before** the child binary gets to run. This diff adds a callback to permit this. The callback is deliberately harder to use than an `std::function`, because you **REALLY HAVE TO KNOW WHAT YOU ARE DOING** to use this. And you have to check your work three times. Even glog `LOG()` must not be called from inside this callback. Your random library of choice is also probably unsafe.

This diff is primarily applicable to job managers and shells. For example, these tasks benefit from this callback: adding a child to a Linux `cgroup`, twiddling its various POSIX process attributes.

Implementing a correct callback for the post-vfork environment is fraught with peril. Read http://ewontfix.com/7/, and the docstrings in this diff.

Reviewed By: yfeldblum

Differential Revision: D2688323

fb-gh-sync-id: aae49e2b3957ca845895acca26e9cb44df1afc07

Summary: Currently, the tryRunAfterDelay implicitly converts a negative delay in int to unsigned int. With this change, the api makes it clear than only unsinged int is accepted as valid delay

Reviewed By: yfeldblum

Differential Revision: D2710034

fb-gh-sync-id: cb3c6b91bb86bbe07fa0e590b2ea871242d19745

Summary:
Change mutex to MicroSpinLock, for constexpr-ctor-ness on OSX.

Fixes this error seen on mac:

  ThreadLocalDetail.h:202:38: note: non-literal type 'std::mutex' cannot be used in a constant expression

Reviewed By: ldemailly

Differential Revision: D2713511

fb-gh-sync-id: bc1c34b4a0ee21347278aa368b408f286345e050

Summary: Small, silly bug which is triggered when there are no keys to unregister, invalidating the current size of the structure.

Reviewed By: yzhan

Differential Revision: D2712604

fb-gh-sync-id: f6f031936d8e4e458b49c08714f42cb2eec4c4fe

Summary: Comes in handy, and std::experimental::optional has it.

Reviewed By: yfeldblum

Differential Revision: D2708324

fb-gh-sync-id: 87cdf2449f356d3baf9fb56a608e9c43d8fe79ae

Summary:
Since this is used in so many places during the program's static-initialization (at startup), this class itself could be (has been demonstrated to be) a point of SIOF problems itself.

Made this class constexpr-constructible, so it doesn't need to be part of static initialization, making it SIOF-proof.

Reviewed By: luciang

Differential Revision: D2709231

fb-gh-sync-id: f248c9f2848c09045e000cfdc03636d847e522c9

Summary: This is a //tiny// documentation change. I noticed that there are lots of places in the codebase where people follow this recommended usage of `with_exception` in an if–else chain, (e.g., https://fburl.com/181606454). IMHO, a short-circuiting `||` operator is easier to read and write.

Reviewed By: yfeldblum

Differential Revision: D2687840

fb-gh-sync-id: 6354555aeba81dcfe7adf17e7e573de0b1206b37

Summary: facepaw

Reviewed By: djwatson

Differential Revision: D2709030

fb-gh-sync-id: 20fe50bc70e97c4fedeae8fd271a4de70fa0e805

Summary: [Folly] Avoid requiring a suppression (`unevaluated-expression`).

I am not a fan of suppressing warnings. This warning comes from the internals of gtest, but anyway.

Replace with something that does not trigger the warning.

Reviewed By: Gownta

Differential Revision: D2706279

fb-gh-sync-id: 2ecac1d230308a8fd21a69565193c52585526448

Summary: Add template parameters to support arbitrary types when looking up a key.

This is useful to avoid the cost of 'materializing' a key which is likely to be present in the array (or, alternatively, switching on a tagged union KeyT).

Use the new capability to greatly simplify the lookup logic in HHVMs static string table.

Reviewed By: nbronson

Differential Revision: D2662451

fb-gh-sync-id: 707fa033f350b80ca8080af17f1a8a74c59f2e88

Summary: Using -Werror and -Wfloat-conversion was causing failure in code that is deliberately
performing that conversion.  Add explicit casts to avoid the warnings/errors.
Here are two of the diagnostics:

  ./folly/Conv.h: In instantiation of "typename std::enable_if<std::is_floating_point<_Tp>::value, Tgt>::type folly::to(folly::StringPiece) [with Tgt = float; typename std::enable_if<std::is_floating_point<_Tp>::value, Tgt>::type = float; folly::StringPiece = folly::Range<const char*>]":
  ./thrift/lib/cpp2/protocol/SimpleJSONProtocol.tcc:687:28:   required from "T apache::thrift::SimpleJSONProtocolReader::castIntegral(const string&) [with T = float; std::string = std::basic_fbstring<char>]"
  ./thrift/lib/cpp2/protocol/SimpleJSONProtocol.tcc:680:26:   required from "uint32_t apache::thrift::SimpleJSONProtocolReader::readJSONKey(T&) [with T = float; uint32_t = unsigned int]"
  ./thrift/lib/cpp2/protocol/SimpleJSONProtocol.tcc:654:16:   required from "uint32_t apache::thrift::SimpleJSONProtocolReader::readInContext(T&) [with T = float; uint32_t = unsigned int]"
  ./thrift/lib/cpp2/protocol/SimpleJSONProtocol.tcc:1035:34:   required from here
  ./folly/Conv.h:1222:31: error: conversion to "float" from "std::enable_if<true, double>::type {aka double}" may alter its value [-Werror=float-conversion]

  ./folly/Conv.h: In instantiation of "typename std::enable_if<((std::is_integral<_Tp2>::value && std::is_floating_point<_Tp>::value) || (std::is_floating_point<_DInputType>::value && std::is_integral<_Tp>::value)), Tgt>::type folly::to(const Src&) [with Tgt = long int; Src = double; typename std::enable_if<((std::is_integral<_Tp2>::value && std::is_floating_point<_Tp>::value) || (std::is_floating_point<_DInputType>::value && std::is_integral<_Tp>::value)), Tgt>::type = long int]":
  ./folly/dynamic-inl.h:636:51:   required from "T folly::dynamic::asImpl() const [with T = long int]"
  ./folly/dynamic-inl.h:384:64:   required from here
  ./folly/Conv.h:1245:16: error: conversion to "long int" from "double" may alter its value [-Werror=float-conversion]

This change deserves a little more explanation:

  -  return ceil((double(sizeof(IntegerType) * CHAR_BIT) * M_LN2) / M_LN10);
  +  return (unsigned int)(ceil(sizeof(IntegerType) * CHAR_BIT * M_LN2 / M_LN10));

In addition to adding the cast to destination type, I have also removed the unnecessary cast to double of the first product (there is not risk that it will overflow, and no need to promote to double, there), and I have also removed the grouping parentheses, since the standard left-to-right evaluation works just fine here.

Reviewed By: Gownta, yfeldblum

Differential Revision: D2703928

fb-gh-sync-id: 23b49281d9120d106f1fdbd30921e8f39c01367d

Summary: CodeMod: Use the `ExceptionWrapper::with_exception` variant that deduces exception types.

Since we must specify the exception type in the lambda arg, and there is a variant of `ExceptionWrapper::with_exception` that deduces the type of the exception from the type of the lambda arg, we don't need to specify the exception type again as a template parameter anymore.

Reviewed By: meyering

Differential Revision: D2694895

fb-gh-sync-id: 505469f9008973a315e836f356e5db97df4ec921

Summary: Do not negate signed numbers like INT_MIN or INTMAX_MIN, since
that would evoke undefined behavior.  Otherwise, the test (below)
would fail with this run-time error:

  [ RUN      ] Conv.Integral2String
  folly/Conv.h:521:47: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself

Reviewed By: markisaa

Differential Revision: D2704195

fb-gh-sync-id: 4036437fb972109672004163880078127e7df797

Summary: [Folly] Avoid deprecated `Singleton<T>::get()` in `folly/futures`.

Changes `getTimekeeperSingleton()` to return a `shared_ptr<Timekeeper>`, and patches its call-sites.

Additionally, have the call-sites keep the singleton instance alive for the duration that it is being directly used.

Reviewed By: ddrcoder

Differential Revision: D2702361

fb-gh-sync-id: 82b72ee514dc4f2a7f7522af8b2e92b34df063d6

Summary: get_weak() is always used with .lock(), but try_get() is actually more performant than get_weak().lock().
Using get_weak() to store a weak_ptr and keep locking is not safe in fork scenarios.

Reviewed By: yfeldblum

Differential Revision: D2694223

fb-gh-sync-id: 908d44293ffd9b3782152d43e28d5de172d1654a

Summary: [Folly] Fix `ExceptionWrapper::with_exception` to support lvalue ref functors.

Ex:

    auto handler = [&](const std::runtime_error& e) { handle_runtime_error(e); };
    exception_wrapper wrap = get_some_exception_wrapper_from_context();
    wrap.with_exception(handler); // broken before this diff, fixed after

Reviewed By: markisaa

Differential Revision: D2698680

fb-gh-sync-id: 4976ba08e3601e22891d00d79a5dae5118887b71

Summary: This changes ReadMostlySharedPtr API to have 3 types: MainPtr, WeakPtr, SharedPtr. MainPtr and SharedPtr are equivalents of std::shared_ptr, and WeakPtr is an equivalent of std::weak_ptr. The only difference is that it can only be a single MainPtr, and while it's alive copying SharedPtr/WeakPtr or WeakPtr doesn't require atomic operations (and thus can be more performant than std::shared_ptr). Unlike original ReadMostlySharedPtr API, there're no thread-safety guarantees between reset() and getShared() for ReadMostlySharedPtr.

ReadMostlySharedPtr can work with different RefCount implementations. This diff introduces RCURefCount (which is currently using liburcu) and TLRefCount.

Reviewed By: djwatson

Differential Revision: D2683572

fb-gh-sync-id: a7a03af4b1cf5f81a613368c6eebe70b2eaef064

Summary: So far this is a speculative fix.. I am waiting to see the results from the Ubuntu machine, but I suspect this is the problem.

Reviewed By: bugok

Differential Revision: D2697600

fb-gh-sync-id: e33d452a52c5ace2b7401d6495621ce68a5076b5

Summary: See D2696092

Reviewed By: meyering

Differential Revision: D2696360

fb-gh-sync-id: 2cfa9258be899a93a58c59dae70a10fef6f457c8

Reviewed By: philippv

Differential Revision: D2696314

fb-gh-sync-id: 105de2d99bb9f5ac82310e37f9302022c103befc

Summary: Make these more spurious failure-aware/tolerant.

Reviewed By: yfeldblum

Differential Revision: D2689775

fb-gh-sync-id: 1a9b247b97cc3529b12f6f7b76a4af2e32822d45

Summary: [technically, the existing code is probably a no-op on
all systems we care about, but since it is officially UB, switching
to a more strict platform could cause trouble, so it's worth fixing]

Calling memcpy with "nullptr" as 2nd argument is undefined, even when
the third argument is zero, and causes a failure when testing with an
UBSAN-enabled binary (-fsanitize=undefined).
Before this change, the buck-run test below would evoke this failure:

  [ RUN      ] ThreadLocalPtr.BasicDestructor
  folly/detail/ThreadLocalDetail.h:533:29: runtime error: null pointer passed as argument 2, which is declared to never be null
  third-party-buck/build/glibc/include/string.h:47:45: note: nonnull attribute specified here

Ironically, the failure of the target-determinator-buck_push_blocking test (due to an unrelated proxygen dep problem) would block me from landing this, so I am adding this line to override it.

Reviewed By: luciang, alexshap

Differential Revision: D2692625

fb-gh-sync-id: 8bdc5cd2899705f39c9565d640921de1f363807d

Reviewed By: ot

Differential Revision: D2695741

fb-gh-sync-id: d33263c1ffa5651d66f37992ce365dae157ed449

Summary: `goodMallocSize` is used extensively in `folly` data structures,
especially for containers optimized for small contents, such as
`fbstring` and `small_vector`.

However, it makes the design decision to align the allocation size to
a x86 cache line, forcing a minimum allocation size of `64` bytes,
despite jemalloc can provide smaller size classes (8, 16, 32,
48). This causes a large discontinuity between small contents that can
be inlined and heap-allocated contents:

- For `fbstring`, a string of 23 bytes (including terminator) occupies
  24 bytes (`sizeof(fbstring)`), a string of 24 bytes occupies 24 + 64
  + allocation overhead when it could be 24 + 32 + allocation
  overhead. The waste is more than 50%.

- For `small_vector<uint32_t, 1, uint32_t>`, for instance, a vector
  with 1 element occupies 12 bytes, a vector with 2 elements occupies
  12 + 64 + allocation overhead when it could be 12 + 8 + allocation
  overhead. The waste is more than 250%.

With this diff we just trust jemalloc and always use `nallocx`. If a
data structure need cache-line alignment it should be implemented at
its level.

Reviewed By: elsteveogrande

Differential Revision: D2688156

fb-gh-sync-id: 46548d4a91952e7c673d4f0997c4c067e03c190d

Summary: [Folly] A well-known instance of `folly::Unit`.

Reviewed By: jsedgwick

Differential Revision: D2693426

fb-gh-sync-id: fe595abc852500275a827b4f400cfda7091a55f7

Summary: [Folly] `ExceptionWrapper::with_exception` variant deducing exception type from functor type.

From the `README.md`:

    // TODO(jsedgwick) infer exception type from the type of the function

Reviewed By: Gownta

Differential Revision: D2685579

fb-gh-sync-id: 158bcd030019f28b4f392d17167ab0bd67cc1edb

Summary: Make jemalloc's sdallocx function available in folly and allow future code to
use sized deallocation.

Reviewed By: elsteveogrande, ot

Differential Revision: D2687746

fb-gh-sync-id: 9ef8a16d2c63c4eb8cecab7639add423ef093c2d

Summary: [Folly] Fix Build: `folly/test/ThreadLocalTest`.

The problem is that the to the shared lib used in the test is hardcoded. It's a relative path, so that's nice, but it has too many assumptions about where the build system deposits test binaries.

Instead, let the code simply look for the shared lib in the same directory as the test binary. This makes fewer assumptions on the build system.

Reviewed By: andriigrynenko

Differential Revision: D2689047

fb-gh-sync-id: 648da079b7af5bc9893709d009e577347dd4a463

Summary: If it takes too long to finish it is probably heavily loaded. Skip if
so.

Reviewed By: mmcduff

Differential Revision: D2687346

fb-gh-sync-id: 282cac7e4df361f714de1089f11b098af79b1512

Summary: It looks like there is no reason to catch a `std::exception` and then `dynamic_cast` to a derived exception. We can just catch the derived exception directly.

whatcouldgowrong4

Reviewed By: yfeldblum

Differential Revision: D2677284

fb-gh-sync-id: 0149e4d4aecc96257376d410f592620205441f66

Summary: We wanted to compare the benefits of using folly::to<std::string> directly, and decided this benchmarking might as well be contributed back to folly.  Here are the results:

```
  ============================================================================
  folly/test/ConvTest.cpp                         relative  time/iter  iters/s
  ============================================================================
  ...
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1)                                  157.88ns    6.33M
  u64ToStringFollyMeasure(1)                       212.52%    74.29ns   13.46M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12)                                 158.14ns    6.32M
  u64ToStringFollyMeasure(12)                      212.55%    74.40ns   13.44M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123)                                152.26ns    6.57M
  u64ToStringFollyMeasure(123)                     210.95%    72.18ns   13.85M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234)                               152.40ns    6.56M
  u64ToStringFollyMeasure(1234)                    204.82%    74.41ns   13.44M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345)                              156.01ns    6.41M
  u64ToStringFollyMeasure(12345)                   208.90%    74.68ns   13.39M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123456)                             178.21ns    5.61M
  u64ToStringFollyMeasure(123456)                  238.77%    74.63ns   13.40M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234567)                            161.38ns    6.20M
  u64ToStringFollyMeasure(1234567)                 203.09%    79.46ns   12.58M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345678)                           159.01ns    6.29M
  u64ToStringFollyMeasure(12345678)                192.42%    82.64ns   12.10M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123456789)                          169.07ns    5.91M
  u64ToStringFollyMeasure(123456789)               203.70%    83.00ns   12.05M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234567890)                         166.56ns    6.00M
  u64ToStringFollyMeasure(1234567890)              187.21%    88.97ns   11.24M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345678901)                        176.22ns    5.67M
  u64ToStringFollyMeasure(12345678901)             197.57%    89.20ns   11.21M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123456789012)                       174.74ns    5.72M
  u64ToStringFollyMeasure(123456789012)            182.52%    95.74ns   10.45M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234567890123)                      178.47ns    5.60M
  u64ToStringFollyMeasure(1234567890123)           186.81%    95.54ns   10.47M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345678901234)                     187.33ns    5.34M
  u64ToStringFollyMeasure(12345678901234)          184.05%   101.78ns    9.82M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123456789012345)                    198.16ns    5.05M
  u64ToStringFollyMeasure(123456789012345)         182.48%   108.59ns    9.21M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234567890123456)                   182.56ns    5.48M
  u64ToStringFollyMeasure(1234567890123456)        164.19%   111.19ns    8.99M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345678901234567)                  186.80ns    5.35M
  u64ToStringFollyMeasure(12345678901234567)       162.33%   115.07ns    8.69M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(123456789012345678)                 195.08ns    5.13M
  u64ToStringFollyMeasure(123456789012345678)      165.51%   117.87ns    8.48M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(1234567890123456789)                200.27ns    4.99M
  u64ToStringFollyMeasure(1234567890123456789)     164.62%   121.65ns    8.22M
  ----------------------------------------------------------------------------
  u64ToStringClibMeasure(12345678901234567890U)              203.18ns    4.92M
  u64ToStringFollyMeasure(12345678901234567890U)   162.38%   125.13ns    7.99M
  ----------------------------------------------------------------------------
  ...
  ============================================================================
```

Reviewed By: yfeldblum

Differential Revision: D2680998

fb-gh-sync-id: 179fbd756c714c92b7230d3750af024865ecbb0a

Summary: Closes https://github.com/facebook/folly/issues/304

Reviewed By: yfeldblum

Differential Revision: D2685289

fb-gh-sync-id: 563697fb01ee358472b9080058848d2b557ba466

Summary: 'flating point' => 'floating point'

Closes https://github.com/facebook/folly/issues/241

Reviewed By: yfeldblum

Differential Revision: D2685280

fb-gh-sync-id: 2e9c2b5419d0c631af4a32c5ab6b7366033ca34c

Summary: Make PthreadKeyUnregister a global singleton for all StaticMeta instances.

Reviewed By: luciang

Differential Revision: D2678401

fb-gh-sync-id: c0d58b483fa6f096b29aeb7df71897a75ea8c892

Summary: This reverts commit 9d355f96c4fe073c889f28070d5952fa4eb007a0.

build-break

Reviewed By: sctaylor

Differential Revision: D2680784

fb-gh-sync-id: a2df233bcd3721ffbfcd6fd71ea3cabbebebd4c4

Summary: D2613681 codemod'ed a thrift server api but it also renamed that api
in AsyncServerSocket, which is a mistake. Fix that in AsyncServerSocket, and
all other places that calls this api.

Reviewed By: alandau, JoelMarcey

Differential Revision: D2677837

fb-gh-sync-id: 0d91f1a623229e99be59ca9dcd27f1330a9a1b64

Summary: Remove unnecessary resetClientHelloParsing callback which causes problems wiht
Openssl 1.0.2

Reviewed By: knekritz

Differential Revision: D2664730

fb-gh-sync-id: d1b55ae493b4c92627ad41e7bf85f1e1a777bd2b

Summary: Remove busy wait from Future::wait.
If future.wait(timeout) has succeded we should
return a ready future, otherwise we should return a future
for the final result (not necessarily ready).

Reviewed By: yfeldblum

Differential Revision: D2646860

fb-gh-sync-id: 62671d09073ad86e84df8c9257e961d2a8c2a339

Summary: Without feedback that a `moveForward` or `moveBackward` did nothing, a user
cannot implement this idiom safely:

```
while(rb.tryRead(entry, cursor)) {
  doSomething(entry);
  cursor.moveBackward();
}
```

In the case where the ring buffer has not overflowed and slot 0 is still
available, the reader will get stuck at it (read it continuously) until
the buffer overflows.

This diff allows the above example to become:

```
while(rb.tryRead(entry, cursor)) {
  doSomething(etnry);
  if (!cursor.moveBackward()) {
    break;
  }
}
```

Reviewed By: bryceredd

Differential Revision: D2674975

fb-gh-sync-id: a0c5857daf186ef19e203f90acc2145590f85c3b