Reviewed By: yfeldblum

Differential Revision: D21921631

fbshipit-source-id: e905d6d2a96775a8c3b328fb78c8d32897f634f6

Summary: connect will automatically bind the socket if the socket is not bound yet

Reviewed By: yangchi

Differential Revision: D21845740

fbshipit-source-id: 27a5b44476dfc0b2ae5ff2f0a6c1bd4e976eadc9

Summary: [Thrift] Dead Code: `TAsyncSocket`.

Reviewed By: vitaut

Differential Revision: D20851837

fbshipit-source-id: d4279fb1ab712f338d399220df26d56c4ab7076a

Summary:
[Folly] `EventBase::getRecentSteadyTime`, returning a recent `steady_clock::time_point` which is updated each pass through the event loop, but not for each ready event or function.

Assuming everything in the loop is truly asynchronous, this permits callers to get a reasonably accurate approximation of the current time, but for many callers to blend or amortize the cost of getting that current time.

May only be called from the running IO thread.

Differential Revision: D21866783

fbshipit-source-id: 8eb472ce50bf012616e567b29f6724c67ef8d41a

Summary: [Folly] `atomic_ref::compare_exchange_strong` and `atomic_ref::compare_exchange_weak`.

Differential Revision: D21923944

fbshipit-source-id: 55620473ea253782cc1dbb95baef38c96a9fbc70

Summary: This provides a single mechanism to mitigate deadlocks in singleton destructors.

Reviewed By: yfeldblum

Differential Revision: D21827615

fbshipit-source-id: 090bad1a91238310e7814663193711df0f4d622a

Summary: [Folly] Deduction guide for `atomic_ref`.

Reviewed By: markisaa

Differential Revision: D21923854

fbshipit-source-id: 8ad10692b95c653fc65302e6ad0118cbd615a62f

Summary:
All implementations of transports in practice were all AsyncTransportWrappers
(AsyncSocket, AsyncSSLSocket, AsyncFizzBase, etc.).

AsyncTransportWrapper was confusing. The only additional functionality that
it provided was the ability to query underlying transports, a piece of
functionality which makes just as much sense on AsyncTransport.

The simplified model:

"AsyncTransport deals with bidirectional I/O. It is both an AsyncReader, and
an AsyncWriter. It may be nested."

This diff changes AsyncTransportWrapper usages in folly to refer to
AsyncTransport, and aliases AsyncTransportWrapper for compatibility.

Reviewed By: yfeldblum

Differential Revision: D21915048

fbshipit-source-id: 741fad91b8f7c8080f942168f5513b12602cfe9a

Summary:
It was very hard to read without any code highligting.
Pull Request resolved: https://github.com/facebook/folly/pull/1364

Reviewed By: Orvid

Differential Revision: D21921822

Pulled By: yfeldblum

fbshipit-source-id: aa1bc39a5d38b055fe4370ccd4ac0b7d5e0273d4

Summary:
[Folly] Add missing `#include <sys/wait.h>` in `folly/test/RandomTest.cpp`.

Fixes https://github.com/facebook/folly/issues/1371.

Reviewed By: Orvid

Differential Revision: D21910410

fbshipit-source-id: 31a045960b2e67282fa77595dfdf840c338ef661

Summary:
[Folly] Mark `_r_debug` imports as weak imports. `_r_debug` is available in `<link.h>` but is not a portable API, so detect whether it is available at runtime and use it only if it is available.

Fixes: https://github.com/facebook/folly/issues/1373.

Reviewed By: Orvid

Differential Revision: D21911715

fbshipit-source-id: 660c0bc90d405d9a43826e7bdfc3b04480728b66

Summary: [Folly] Cut dead code: `countLoadedElfFiles()`.

Differential Revision: D21910945

fbshipit-source-id: 43ff7d118b4876e2cbd4527713c8552963810537

Summary:
[Folly] Let `ElfCache` be unbounded to permit binaries with many dynamically-linked libraries from continuously missing the cache when symbolizing.

Some applications symbolize stacktraces relatively frequently. When the build is using dynamic linking, such as might be done when developing the application or running the unit-tests, the overhead from re-loading `ElfFile` instances can appear. Address this by making the cache be unboundedly large.

This is unlikely to affect applications built using mostly-static linking, such as might be done for production builds, even when they are large applications built from many libraries, since the capacity parameter is usually much larger than the total number of dynamically loaded libraries.

Currently, no substantial work is done when initializing `ElfFile` instances. If substantial work were to be done, especially in an unoptimized build such as might be used when developing the application or running the unit-tests, and instances do not stay in cache, then that substantial work would be repeated whenever symbolizing stacktraces rather than being amortized.

Reviewed By: luciang

Differential Revision: D18819555

fbshipit-source-id: 0e75326133e901e7bd49ea3cefe9b318e6d4466f

Summary: It's possible that we still have a recurring pool resizer task scheduled after virtual event base is destroyed. This changes makes sure that we don't try to reschedule it if VirtualEventBase is already destroyed.

Reviewed By: yfeldblum

Differential Revision: D21875241

fbshipit-source-id: c4622c5d103c6291386055c153ab4aeebe7795a2

Summary:
In 0ae204a978c11ddefafd81bd319a078239a44c1c the 'projects_dir' option
became a required constructor argument since it is called within the
constructor. However, it has not been adjusted in the subclasses that
used to set the option after instantiation. This commit fixes the
'shell_builder' and the 'debian_system_builder'.
Pull Request resolved: https://github.com/facebook/openr/pull/50

Test Plan:
1. Go to build directory: `cd build`
2. Run the `shell_builder` & `debian_system_builder`:
    - `python fbcode_builder/shell_builder.py`
    - `python debian_system_builder/debian_system_builder.py`

`shell_builder` output before:
```
Traceback (most recent call last):
  File "fbcode_builder/shell_builder.py", line 102, in <module>
    builder = ShellFBCodeBuilder()
  File "/home/butjar/tu/ma/openr/build/fbcode_builder/fbcode_builder.py", line 93, in __init__
    self._github_dir = self.option('projects_dir')
  File "/home/butjar/tu/ma/openr/build/fbcode_builder/fbcode_builder.py", line 108, in option
    raise RuntimeError('Option {0} is required'.format(name))
RuntimeError: Option projects_dir is required
```

`shell_builder` output after:
```
set -exo pipefail
export CCACHE_DIR='/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr/.ccache' CC="ccache ${CC:-gcc}" CXX="ccache ${CXX:-g++}"
### Diagnostics ###

# Builder ShellFBCodeBuilder(google/googletest:cmake_defines={u'BUILD_GTEST': u'ON', u'BUILD_SHARED_LIBS': u'OFF'}, google/googletest:git_hash=u'release-1.8.1', facebook/openr:local_repo_dir='/home/butjar/tu/ma/openr', facebook/zstd:git_hash=ShellQuoted(u'$(git describe --abbrev=0 --tags origin/master)'), openr/build:cmake_defines={u'ADD_ROOT_TESTS': u'OFF'}, thom311/libnl:git_hash=u'libnl3_2_25', projects_dir=u'/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr', fmtlib/fmt:git_hash=u'5.3.0', wangle/wangle/build:cmake_defines={u'BUILD_TESTS': u'OFF'}, prefix=u'/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr/installed', fizz/fizz/build:cmake_defines={u'BUILD_TESTS': u'ON'}, ccache_dir=u'/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr/.ccache', zeromq/libzmq:git_hash=u'v4.2.2', make_parallelism=4, jedisct1/libsodium:git_hash=u'stable')
hostname
cat /etc/issue || echo no /etc/issue
g++ --version || echo g++ not installed
cmake --version || echo cmake not installed

### Check out fmtlib/fmt, workdir build ###

mkdir -p '/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr' && cd '/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr'
git clone  https://github.com/'fmtlib/fmt'
mkdir -p '/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr'/'fmt'/'build' && cd '/home/butjar/.fbcode_builder-sZshomesZsbutjarsZstusZsmasZsopenr'/'fmt'/'build'
git checkout '5.3.0'

### Build and install fmtlib/fmt ###

...
```

Reviewed By: steven1327

Differential Revision: D21865881

Pulled By: saifhhasan

fbshipit-source-id: dfd78127d3b2c78721f84a3ecafe0b7198c38f06

Summary:
Typo in python shebang introduced by 0d19e27, probably by accident.

Found while skimming the code.
Pull Request resolved: https://github.com/facebook/openr/pull/51

Reviewed By: steven1327

Differential Revision: D21865922

Pulled By: saifhhasan

fbshipit-source-id: 5f2c2c2fac82078070920915812139f5fef1c7fe

Summary: [Folly] Move `AlignedSysAllocator` computation of max value over input alignment values from two places to a single place.

Differential Revision: D19229096

fbshipit-source-id: 4e95c7b7e0afe99c37116150184eb180683c7d13

Reviewed By: StanislavGlebik

Differential Revision: D21549859

fbshipit-source-id: 0e143354a60578732ae1eed8c3c71b9f859e3958

Summary: Currently output from build command is decoded with "surrogateescape" error handler, but when writing to log files/stdout we don't specify error handlers to be also "surrogateescape" according to https://docs.python.org/3/library/codecs.html#error-handlers, which could cause exception when there's surrogate characters logged in message.

Reviewed By: yfeldblum

Differential Revision: D21850411

fbshipit-source-id: 21c51d1ab2132171ae29f2d1fbe42655ebee94c5

Summary:
When a session is newly negotiated, pass it to the SSLSession belonging to the corresponding AsyncSSLSocket through SSLSessionManager. That SSLSession then becomes resumable.

This allows SSLSessions obtained from an AsyncSSLSocket to later become resumable once the session is negotiated (asynchronously in TLS 1.3).

Reviewed By: yfeldblum

Differential Revision: D21035731

fbshipit-source-id: acbaa258798e7774e742c5765ef33e24573f1c78

Summary: Refactor AsyncSSLSocket session code into a new class called SSLSessionManager, which is a member of AsyncSSLSocket. Will allow for SSLContext to interact with SSLSession through SSLSessionManager, without depending on AsyncSSLSocket.

Reviewed By: yfeldblum, mingtaoy

Differential Revision: D21164020

fbshipit-source-id: e6b38336127fb000587bfe6948c2274afe8d85e0

Summary: codecleanupraccoon

Reviewed By: mjoras

Differential Revision: D21845742

fbshipit-source-id: 5adf159ed4ec7a48c76cffdb02d039888ab1686d

Summary:
Update fmt version to 6.2.1 for better compatibility with the version used in fbcode. Among other things this fixes fbthrift build failure on Travis:

```
/home/fbthrift/thrift/lib/cpp2/async/RocketClientChannel.cpp:70:67:   required from here
/home/install/include/fmt/core.h:492:3: error: static assertion failed: don't know how to format the type, include fmt/ostream.h if it provides an operator<< that should be used
```
which is caused by trying to format an enum class without a formatter - only supported as of 6.0.

Reviewed By: stevegury, avalonalex

Differential Revision: D21860076

fbshipit-source-id: 1857ab65822956b005980b8dfff7a967508f507c

Summary: [Folly] Cut the `FOR_EACH_ENUMERATE` macro, which may be replaced by a combination of range-for, `ranges::view::enumerate`, and structured bindings.

Reviewed By: markisaa

Differential Revision: D21813019

fbshipit-source-id: fc9ac09a4e2f72f1433d0a518f03d5cd69a59c55

Summary: Expose async read/write functionality

Reviewed By: yfeldblum, kevin-vigor

Differential Revision: D21731597

fbshipit-source-id: 95a0af53c7b85e1bf1a2619586091b6633bc7b8a

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

Reviewed By: Orvid

Differential Revision: D21110331

Pulled By: yfeldblum

fbshipit-source-id: 57522232efb7268bc290e4f22057f531a380fb81

Summary:
SemiFuture::within creates two valid SemiFutures and promptly overwrites them, both discarding valid SemiFutures and wasting the core allocation. It later drops the updated versions without directly consuming them, instead stealing the deferred executors.

This update initializes the two SemiFutures as empty, and safely terminates the chain with trivial callbacks so the SemiFutures can be treated as consumed.

Reviewed By: yfeldblum

Differential Revision: D21769500

fbshipit-source-id: eab13a78b17ecfc937b42c8d5e01e1292158d9ed

Differential Revision: D21757385

fbshipit-source-id: 28af042285d343944452e1c2cf94794a121c0e06

Summary:
`value` could trigger "unused parameter" warning in NDEBUG builds. The fix is straightforward, to use the new-ish `[[maybe_unused]]` attribute.

The alternatives are to use `FOLLY_MAYBE_UNUSED` or even manual `(void)value;`. But since this is coroutines library, it should be reasonably safe to assume the compiler supports the cleaner and more expressive native C++17 option.

Reviewed By: lewissbaker

Differential Revision: D21784931

fbshipit-source-id: 895bf95d65df6533d768b65c44a898a73e0a636f

Summary:
There were two problems with the clock_gettime fallback logic on
macOS. One is that it used undefined macros if AvailabilityMacros.h
wasn't included. Another is that it compiled the fallback when the
minimum iPhone OS version (as when building on macOS) was not set, and
vice versa.

Fix that.

Differential Revision: D21757362

fbshipit-source-id: 99fd17260cb25ed07c39ba79466e835f08a1fc7c

Summary:
It may be useful to see if a threadlocal has been created on a thread before accessing it.

One way this could be useful: the data is only relevant to a few threads but will be accessed by many. This would allow you to save the memory on the non-relevant threads.

Differential Revision: D21731260

fbshipit-source-id: 0b1835b454f9b0c457f722ab38f84f89aca383fb

Summary: Add detailed comment to SSL_CTX_set_session_cache_mode call in SSLContext, since any changes can result in breaking functionality or increased memory usage.

Reviewed By: mingtaoy

Differential Revision: D21769914

fbshipit-source-id: 61a172f24cda870d6c13a24d279509e2e2804538

Make collectAll, collectAllRange, collectAllWindowed consistently rethrow exception from first failure

Summary:
The void-returning variants of collectAllRange() and collectAllWindowed() were
previously failing with the error from the first task to fail whereas the other
variants of collectAll() were failing with an arbitrary error (typically first
by argument order) in the case of multiple errors.

This was problematic because after the first task failed it requests cancellation
of the other tasks, which then often will complete with an 'OperationCancelled'
error. This mean that, unless the original error occurred on the first failed
task in argument order, the error that caused the cancellation would be discarded
and instead, the collectAll() operation would result in an 'OperationCancelled'
error.

This change updates those algorithms to now consistently fail with the error
from the first task to fail (in time) as this error will typically be the most
useful in determining the root cause of the failure.

Also it now discards any errors that occur in child tasks if they fail after
cancellation was requested on the parent task. In this case the collectAll()
will complete with an 'OperationCancelled' error.

Also made a few drive-by changes to avoid rethrowing exceptions where possible
by using `co_yield co_error(e)`.

Reviewed By: yfeldblum

Differential Revision: D21681812

fbshipit-source-id: dfe15d0672dcbdeb4e156962cdffe767ddf91a0b

Summary:
Adds the ability to request cancellation of the folly::coro::UnboundedQueue's
dequeue() operation by injecting a CancellationToken using co_withCancellation().

Most of the work for supporting this was implemented in the change to
Semaphore::co_wait() to support cancellation.

This diff just adds some tests for cancellation of UnboundedQueue::dequeue()
and provides a more efficient code-path for the cancellation-case that does
not involve throwing an exception.

Reviewed By: yfeldblum

Differential Revision: D21555325

fbshipit-source-id: 7fbae8aa426b40bbea4d0d6dec85df4bad813733

Summary:
The `Semaphore::co_await()` method now response to requests for cancellation
communicated through the awaiting context's CancellationToken.

This allows interrupting a wait-operation if the result is no longer required,
in which case the co_wait() task completes with the OperationCancelled exception.

Reviewed By: yfeldblum

Differential Revision: D21655946

fbshipit-source-id: 8c7f862580ddebd2b4d3eb3cc3ab5e01ad5ee289

Summary:
Now use an intrusive list structure to store the list of waiters waiting
for the semaphore to be signalled.

This is primarily motivated by the need to support efficient cancellation,
which requires the ability to efficiently remove a specific element from
the waiter list without having to scan the list like we would for the
existing `std::deque`-based list storage.

Another beneift of this change is that it now eliminates memory allocations
that were previously required by the std::deque container.

The `Semaphore::future_wait()` implementation should now also have one fewer
allocations as the allocation of the Baton and the Baton::Waiter are now fused.

Reviewed By: yfeldblum

Differential Revision: D21692257

fbshipit-source-id: 9beff176b250ae3f37df9e2138f93b15d2607353

Summary: These only had a 1 month expiration after D21271202.

Reviewed By: xybu, mingtaoy

Differential Revision: D21765601

fbshipit-source-id: 18b9f400e96b2ba39df650db9e6627f1cf917250

Summary:
If inline functions are enabled, actual frames used can be larger than the
address count.

Reviewed By: luciang

Differential Revision: D21371112

fbshipit-source-id: c1e602b62b6af427f11701bf25894a99f554ec47

Summary:
Baton is the primitive that allows fibers to block. The goal of this diff is to provide an `Async` interface to blocking calls that operate on Batons.

Overloading `await` directly was one option, however, there are 3 blocking baton APIs (wait, try_wait_for and try_wait_until). Morover these APIs can accept arguments (something async::await doesn't do so far)

So, this diff adds a bunch of wrappers that return Async<> results that must be 'awaited' on. This keeps static-analysis happy, and performs the onFiber check.

Reviewed By: yfeldblum

Differential Revision: D21667887

fbshipit-source-id: 774c19d223ebb0932c043e4c09635c5e85cc8241

Summary:
Fix race condition between releaseRefClearDelete and releaseRefDeleteOnly by fixing handling in releaseRefClearDelete of the case where the clear count is 1 and the delete count is > 1.

The correct behavior of releaseRefClearDelete when delete count > 1 is to release the clear count first and then release the delete count, instead of releasing the two counts in one step.

The following sequence of events demonstrates the problem in the absence of the fix:
- clear count == 1 and delete count == 2
- Thread 1 calls releaseRefClearDeleteCount
- Thread 2 calls releaseRefDeleteOnly
- Thread 1 atomically decrements the counts to 0 and 1
- Thread 2 atomically decrements the delete count to 0
- Thread 2 deletes the RequestData object
- Thread 1 call to onClear accesses deleted object

Reviewed By: yfeldblum, davidtgoldblatt

Differential Revision: D21705266

fbshipit-source-id: 8ec2151c4e98968beaef7e9ccec0a786ca5ae267