Summary:
The intent is to use this in a future diff to make packaging a first
class concept; it can be used similarly to how we munge dynamic deps on darwin
systems.

Reviewed By: shri-khare

Differential Revision: D16099931

fbshipit-source-id: c66f994b7c07e903fbf2989946b17a0991e12a91

Summary:
wait.h is a GNU header. The POSIX one is sys/wait.h. Fixes musl warning:

warning redirecting incorrect #include <wait.h> to <sys/wait.h>
Pull Request resolved: https://github.com/facebook/folly/pull/1183

Reviewed By: wez

Differential Revision: D16097571

Pulled By: yfeldblum

fbshipit-source-id: 751e4929bc9f00c99c160be9a7dd904e57ad40ce

Summary:
We're seeing a failure on macOS in a CI environment but don't have much context:

```
Stderr:
+ GETDEPS=opensource/fbcode_builder/getdeps.py
+ opensource/fbcode_builder/getdeps.py test --facebook-internal watchman
Traceback (most recent call last):
  File "opensource/fbcode_builder/getdeps.py", line 436, in <module>
    sys.exit(main())
  File "opensource/fbcode_builder/getdeps.py", line 422, in main
    return args.func(args)
  File "opensource/fbcode_builder/getdeps.py", line 342, in run
    builder.run_tests(install_dirs, schedule_type=args.schedule_type)
  File "/data/sandcastle/boxes/trunk-hg-fbcode-fbsource/fbcode/opensource/fbcode_builder/getdeps/builder.py", line 372, in run_tests
    buck_test_info = list_tests()
  File "/data/sandcastle/boxes/trunk-hg-fbcode-fbsource/fbcode/opensource/fbcode_builder/getdeps/builder.py", line 352, in list_tests
    data = json.loads(output.decode("utf-8"))
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py", line 338, in loads
    return _default_decoder.decode(s)
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/opt/homebrew/Cellar/python27/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
```

Add some more context to that error message so we can learn more.

Reviewed By: pkaush

Differential Revision: D16061528

fbshipit-source-id: 23603a5d18651d20641ef1987b7094e73a9b1dbe

Summary: On Windows "--vcvars-path" can be passed to point to the toolchain we want to use.

Reviewed By: wez

Differential Revision: D15926044

fbshipit-source-id: 2b0cde793f7c7f8473b78afde8794640bae351f3

Reviewed By: udippant

Differential Revision: D16075865

fbshipit-source-id: 172aed7ebbfce987c78eea06e588048b0e2a755f

Summary:
NotificationQueue, although mostly not used as such, is a multi consumer queue and it's missing benchmarks for that part.

There where also a couple of issues with original benchmark which this diff addresses:
1. Benchamrks used to do N * number of producers number of iterations and didn't report increased iteration count back to benchmark
2. Benchmark would not run the same case during whole benchmark time as producers where stopped as soon as they produced enough request and consumer would finish without contention

Since these are very tight loops I added a busy loop param which can be varied the same way as batching parameter.
This param adds some work in a form of a busy loop in both producers and consumer to make benchmarking cases, where producers/consumers are actually doing something except from posting to the queue, easier.

Reviewed By: yfeldblum

Differential Revision: D16071580

fbshipit-source-id: c75f2dd9ae8617be09834cdf153a4b4ae06aaaca

Summary: While congested throughput is important it is also important not to regress non congested path too much.

Reviewed By: aary

Differential Revision: D16005428

fbshipit-source-id: 7b98a7ef253fc306b3097f7236b57a5d453ed15d

Summary: [Folly] Check for max value in test semaphore, beyond which posts cannot be tolerated.

Reviewed By: aary

Differential Revision: D15938166

fbshipit-source-id: 1f3fee97a9662dafc5b434c0449831147aa3c976

Summary:
Remove all the autoconf files.
And fully switch to the cmake build

Reviewed By: udippant

Differential Revision: D16066986

fbshipit-source-id: 9e3082dded77ce85449cf5a3a03bed31c16b711f

Summary:
Folly's `folly/lang/Align.h` header defines `folly::max_align_t`, which is usually taken from stdlib. This is to correct an error in legacy implementations of `std::max_align_t`, by logically reconstructing the maximum alignment value in a constexpr context.

`max_align_t` depends on the function `detail::max_align_`, which is supposed to implement a recursive max value function using templates. However, the expression

```
!(a < e) ? a : max_align_(e, es...)
```

does not recursively compute the maximum value over `a`, `e`, `es...`. This expression actually selects the first value that is followed by a lower value.

This error prevents folly from compiling on newer versions of clang, targeting x86, because `folly/CachelinePadded.h` statically checks `max_align_t` in an assertion, and then fails, because it thinks that `AtomicStruct<LifoSemHead, atomic>` is over-aligned.

This corrects the implementation to:

```
!(a < e) ? max_align_(a, es...) : max_align_(e, es...)
```

Pull Request resolved: https://github.com/facebook/folly/pull/1180

Reviewed By: Orvid

Differential Revision: D16079107

Pulled By: yfeldblum

fbshipit-source-id: 13adbd6d1c117b3c547e7116216ee1069129b3c7

Summary:
The source we were downloading from (netfilter.org) should work, but
unfortunately, is donw. This is causing getdeps FBOSS builds to fail. For now,
download from a mirror which seems to be up.

If this becomes a frequent issue with this repository/others, we can consider a
different solution.

Also, not sure how lfs pointer edit was missed by previous commit, added here.

Reviewed By: phshaikh

Differential Revision: D16070052

fbshipit-source-id: dd9278254c77e1a5845ca331a9eeb36f2bf03071

Reviewed By: yfeldblum

Differential Revision: D16054275

fbshipit-source-id: 266f2244fd4c28e1726f4f84d32d4f5d6856ec26

Summary:
Second attempt at https://github.com/facebook/folly/pull/1173

This time the class template specializations are guarded with the `__cpp_noexcept_function_type` feature test macro to maintain compatibility with C++14.

Open to replacing the raw macro with something like `FOLLY_POLY_NOEXCEPT_FUNCTION_TYPE` but that was not my first approach since it's more characters and there is not an extra case to test like with `FOLLY_POLY_NTTP_AUTO`.
Pull Request resolved: https://github.com/facebook/folly/pull/1178

Reviewed By: yfeldblum

Differential Revision: D16057403

Pulled By: Orvid

fbshipit-source-id: 9b538c0f1b0614e69447202d1e4d60ed3fa709cb

Summary: `_mm_crc32_u64` requires SSE 4.2, not just any SSE.

Reviewed By: vener91

Differential Revision: D16032673

fbshipit-source-id: 13cb6299e14184b30a9a04f2644aee2f0cd1a60e

Summary:
Clang defines `_MSC_VER` on Windows, but it is not MSC.

```
% ./third-party/toolchains/llvm/8.0.0/bin/windows/clang.exe -march=corei7 -dM -E -x c empty | grep MSC
#define _MSC_BUILD 1
#define _MSC_EXTENSIONS 1
#define _MSC_FULL_VER 191225835
#define _MSC_VER 1912
```

We are not allowed to define `__SSE4_2__` in clang when clang assumes older arch, because in that case it refuses to compile SSE intrinsics, there is a couple of places in folly where we assume defined `__SSE4_2__` to use SSE4.2 intrinsics.

On the other hand clang defines `__SSE4_2__` itself when it is available:

```
% ./third-party/toolchains/llvm/8.0.0/bin/windows/clang.exe -march=corei7 -dM -E -x c empty | grep SSE
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE4_2__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSSE3__ 1
```

This is an example clang error on Windows:

```
folly/container/detail/F14Table.h:1098:23: error: always_inline function '_mm_crc32_u64' requires target feature 'sse4.2', but would be inlined into function 'splitHash' that is compiled without support for 'sse4.2'
      std::size_t c = _mm_crc32_u64(0, hash);
```

Reviewed By: vener91

Differential Revision: D16038436

fbshipit-source-id: 8728a8d91cadb936c9e244795c9270943fe005ad

Summary: https://github.com/google/sanitizers/issues/970

Reviewed By: yfeldblum

Differential Revision: D16037542

fbshipit-source-id: 8c2feb85454ae582498d38a474e8d5913c9438b1

Summary: Allows futures::retrying to take a continuation that returns a SemiFuture, and in that case to return a SemiFuture as the result.

Reviewed By: andriigrynenko

Differential Revision: D15876742

fbshipit-source-id: da6f1614dd940b83ca048ecedf3d3645aa69b1f0

Summary:
Adding ability to get the current number of bytes used in the tx
(transmit/send) socket buffer and the rx (receive) socket buffer.

Reviewed By: yfeldblum

Differential Revision: D15966995

fbshipit-source-id: 29a51cd4caad265590baa45385712659fb3f3dac

Summary: ported the properties header from unifex and added some simple compile tests

Reviewed By: ericniebler

Differential Revision: D15144375

fbshipit-source-id: 580f8c8977abd070333779898f3ac47510932f87

Summary: `FiberManagerInternal.h` uses `FOLLY_TLS` and `FOLLY_EXPORT` defines which are defined in `folly/Portability.h`.

Reviewed By: vener91, Orvid

Differential Revision: D16020265

fbshipit-source-id: 7f80b397bd364cc53efb67568293da5c90fe97d9

Summary: Original commit changeset: bb2af75d24d6

Reviewed By: yfeldblum

Differential Revision: D15998293

fbshipit-source-id: 9a5ba878f7571bd86dc4c2b6aa72b8764f631ffc

Summary:
adds customizations for folly::Executor folly::EventBase and related types.
The customizations make folly::Executor::KeepAlive<T> model the pushmi Executor, TimeExecutor, and Strand concepts as appropriate

Reviewed By: ericniebler

Differential Revision: D15418629

fbshipit-source-id: d74a777ca743b5fb72664d9c1527837c3fbdb3ba

Reviewed By: snarkmaster

Differential Revision: D15730421

fbshipit-source-id: 51eaac2ad443aadbab3ba772e651287c6b330408

Summary: interval_repeat is an algorithms for single senders. it repeats the predecessor single at the start time and again on an interval relative to that start time. the last parameter is an optional function that allows the time used for the next schedule to be modified.

Reviewed By: ericniebler

Differential Revision: D15945618

fbshipit-source-id: d03cf079d870ceb65e9502c9ff0edcb87b6fd25e

Summary:
Fixes https://github.com/facebook/folly/issues/737

My use of `std::add_pointer_t` deviates in style from the alias decls in other `SignatureOf_` specializations because it is not possible with that syntax to declare a pointer to `noexcept` function.
Pull Request resolved: https://github.com/facebook/folly/pull/1173

Reviewed By: yfeldblum

Differential Revision: D15906742

Pulled By: Orvid

fbshipit-source-id: bb2af75d24d620f80b26ca4daa579e244be0e6a8

Summary: [Folly] Avoid unnecessary ping-pong in portable test semaphore wakeup when `wait()` is called without callback arguments.

Reviewed By: nbronson

Differential Revision: D15903121

fbshipit-source-id: c40018bbd0c49f5114a340a9b97c8cc9f8f70a7c

Summary: [Folly] Fix test semaphore crash when post races with dtor after wait.

Reviewed By: nbronson

Differential Revision: D15896692

fbshipit-source-id: a7caf9795b76c2a6eaa929b907e160107570160d

Summary:
The integration with folly::Synchronized has not landed, remove the comment that
mentions it

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D15891316

fbshipit-source-id: 890ddb85e36605ddec418e782d1f168ddd0cf66e

Reviewed By: yfeldblum

Differential Revision: D15929165

fbshipit-source-id: 476dd6a69d232642437ac65f0519db5acc3a0608

Summary:
Introduces a `FOLLY_NTTP_AUTO` macro to test if NTTP is available.

As per [cppreference](https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros), the macro `__cpp_nontype_template_parameter_auto` is the correct feature test macro to use for the NTTP used to define poly member list. The `__cpp_template_auto` version is checked too, but it was [deprecated](https://fossies.org/diffs/gcc/8.2.0_vs_8.3.0/gcc/c-family/ChangeLog-diff.html) in gcc 8.3 and not supported at all in MSVC.
Pull Request resolved: https://github.com/facebook/folly/pull/1174

Reviewed By: yfeldblum

Differential Revision: D15906768

Pulled By: Orvid

fbshipit-source-id: 831213ec1214a234246bb6b01be89574a0cace25

Summary:
This diff restricts use of memory_resource to C++17 or later,
to avoid problems with compilation on some MSVC platforms.

Reviewed By: kevinhu88

Differential Revision: D15923470

fbshipit-source-id: 91b2446c096fbcb71c8bf5a0f1967bff4cbd1ce8

Summary: [Folly] Use the portable test semaphore in `DeterministicSchedule`, v.s. `sem_t` which is not portable everywhere. The portable test semaphore is implemented purely in terms of `std::mutex` and `std::condition_variable`, and is therefore portable.

Reviewed By: nbronson

Differential Revision: D15909982

fbshipit-source-id: 63b3e5d16864ffee9fad20bd2ad46730fba220dd

Summary: [Folly] A test semaphore with no wake policy, and a rename of the existing test semaphore template for clarity that it has a wake policy.

Reviewed By: nbronson

Differential Revision: D15909983

fbshipit-source-id: 291566daab4838030e25fce862d42e15f2a4a8aa

Summary:
In Facebook's Buck-based build system, folly/system/MemoryMapping.cpp depends on folly/experimental/io/HugePages.cpp. This works well on Linux, and in theory works well on macOS because HugePages.cpp has no OS-specific code at build time. However, because HugePages.cpp has a transitive dependency on the range-v3 library, and because range-v3 isn't available in Facebook's build system for macOS yet, building HugePages.cpp on macOS fails.

On macOS, avoid MemoryMapping.cpp's dependency on HugePages.cpp (and thus the transitive dependency on range-v3). Use a manual annotation to prevent the Facebook's autodeps tool from forcing the dependency on macOS in Buck. (It looks like autodeps does not interpret `#ifdef __linux__`.)

On Linux (servers), this diff should not change behavior.

This diff does not fix the issue in folly's CMake build system.

Reviewed By: yfeldblum

Differential Revision: D15775751

fbshipit-source-id: 612790caab673c0fc52eb3054aa5789f767c7353

Summary: This diff adds a check in `AsyncLogWriter`'s destructor that checks if its subclass called `cleanup()` to drain all the pending log messages in the queue during destructing.

Reviewed By: yfeldblum

Differential Revision: D15383734

fbshipit-source-id: deca9bdc84d5f514f2d47a250d31a68126d20aad

Summary: This diff moves `onIoError` into `AsyncFileWriter` as it is specifically related to writing to file.

Reviewed By: yfeldblum

Differential Revision: D15324855

fbshipit-source-id: 3929a53aee7febd9185b71dfdb894990dee73413

Summary:
This diff splits `AsyncFileWriter` into two parts: `AsyncLogWriter` and `AsyncFileWriter`, so we could re-use the asynchronous IO operating logic with other types of log writer. See the following diffs for example use case.

`AsyncLogWriter` is a virtual class that provides the asynchronous logic and manages a queue of incoming log messages. The users can write subclasses with this class to provided their own IO implementation by overriding the virtual method `performIO`.

`AsyncFileWriter` is one implementation of the `AsyncLogWriter` that writes incoming log messages to a file.

Most of this diff is simply moving things around. Substantial changes are placed in next diff.

Reviewed By: chadaustin

Differential Revision: D15228054

fbshipit-source-id: 86c3405755099c59aa2df8a310250fded648e413

Summary: It might not be obvious that the parent in Subprocess::Options refers to the parent thread (see man PRCTL(2)).

Reviewed By: yfeldblum

Differential Revision: D15873239

fbshipit-source-id: 2a1cc840281d25030708e4d10e633c7d8a9158ed

Summary: An atomic hash array with zero elements isn't useful in any way, not even as an empty set (due to it not being comparable), and there are multiple places that simply crash if you try to use, so just prevent it from being constructed in the first place.

Reviewed By: yfeldblum

Differential Revision: D15789540

fbshipit-source-id: a811f70fb0e9e21a83dc9aea79ec017ae2d7e0a5

Summary:
The documentation on length() is somewhat ambiguous
when dealing with chains of IOBufs -- it is only clear after
reading implementations that "data" refers to "the data in
this single IOBuf, potentially only part of a chain".

Reviewed By: yfeldblum

Differential Revision: D15830189

fbshipit-source-id: d3319abd2d53a76665442d1b93b78a7d1a77dcc0