Summary:
While adding logging around our socket and looking into `AsyncSSLSocket` it seems like the data that is actually written into the socket is not correctly attributed.  I
added logs and printed out what happens on the socket layer, P56563098 in this paste you can see that the `[fishhook]` logs are actually those added in D3698728.

Those are the actual bytes written onto the socket, in the paste, the bytes that are written by the AsyncSocket::bioWrite method are
the ones that actually get written onto the socket. some of the bytes written into the bio comes from bf_buff.c and bss_mem.c which are not eventually attributed to a
socket message and will be incorrectly counted when getRawBytesWritten/Read invoked on AsyncSSLSocket.cpp

Unfortunately/Fortunately this issue is not symmetrical and does not manifest in the getRawBytesReceived in AsyncSSLSocket, reading the bio for read bytes
correctly attributes the actual number of bytes written on the socket. moreover, pulling the asyncsocket data for getRawBytesRead doesnt give the full read bytes on
wire because SSL_connect and SSL_read dont return the number of bytes they read but return the number of bytes without the TLS bytes used.

siyengar seems like a right person to look at this. so adding him here.

Would love to discuss more about this and am open to iterating more on this solution

Reviewed By: knekritz

Differential Revision: D3698744

fbshipit-source-id: 541aa478778b9607f51db194fcbfe28bd23c737f

Summary:
include linux/membarrier.h if it is available.
Closes https://github.com/facebook/folly/pull/455

Reviewed By: lukenels

Differential Revision: D3714952

Pulled By: Orvid

fbshipit-source-id: 8c85756af2cb132152b2182816becfea138f0149

Summary:
`fbstring::assign()` uses `append()`, which triggers exponential growth, but it's preferable that `assign()` behaves like the `fbstring(const char*, size_t)` constructor, which is tight.

Also rewrite `operator=()` in terms of `assign()`, to avoid duplicating the logic, and refactor the logic of `append()` for the aliasing case so that it uses the same expansion operation as the non-aliasing case.

Reviewed By: luciang

Differential Revision: D3754932

fbshipit-source-id: 5423f2a360b4268b6a05dd0ae9d2fe5bd1eb855d

Summary: D3743475 adds to `Malloc.h` a dependency on another folly header, which breaks it when used in stand-alone mode. This diff moves the include to the right `#ifdef` section.

Reviewed By: Gownta

Differential Revision: D3757819

fbshipit-source-id: 71664ca6a3a47b6e4449a4ef603fedf052c5df3b

Summary: I missed this reference when I moved it to the portability folder. It is already being compiled at its new location.

Reviewed By: yfeldblum

Differential Revision: D3754227

fbshipit-source-id: 357b0c26ddbcefdc7640f6a334150abba90ed711

Summary: MSVC can't handle the array as a constexpr value, but works fine with the char*.

Reviewed By: yfeldblum

Differential Revision: D3705189

fbshipit-source-id: e8208b3f2831a720095641f0e1e72ac63ed845a0

Summary: `std::__throw_bad_alloc()` is defined in `<new>` on OSX, so bring back the `#ifdef` guards that were there previously.

Reviewed By: markw65

Differential Revision: D3749714

fbshipit-source-id: 0338a4cece928fce0b9d33d41c17cfa99a319abe

Summary:
fix(FBString): compile error on instantiate `basic_fbstring` with a `Storage` that is not `fbstring_core<E>`
Closes https://github.com/facebook/folly/pull/398

Reviewed By: ot

Differential Revision: D3714957

Pulled By: yfeldblum

fbshipit-source-id: 1c5d2538b674049f7e1872a0b623ec330dc8d7b2

Summary: It only needed a minor tweak, but the change still had to be made :(

Reviewed By: andriigrynenko

Differential Revision: D3745021

fbshipit-source-id: 286c6db706c3571842006537c6b17f506609e51d

Summary: MSVC didn't like the conversion to using `Expected`, and, after `Expected` was fixed to work under MSVC, conv still needs more changes. Specifically MSVC doesn't understand the single-instantiation form of getting the last element, so we have to switch to a tuple-backed version instead, which requires more template instantions, but produces the same performance at runtime.

Reviewed By: ericniebler

Differential Revision: D3744063

fbshipit-source-id: affcab1574c721d8b9529784d7ca2a46233d9935

Summary:
When calling folly::to<SomeString>(double), generic implementation will
firstly reserve 24 (or 25 when negative value) bytes. This will introduce
a malloc call for most of mainstream string implementation.

But for most cases, a floating point doesn't need 24 (or 25) bytes to
be converted as a string.

This diff try to introduce a special version which does not do string reserve.

Reviewed By: ericniebler

Differential Revision: D3728171

fbshipit-source-id: d70ead396ad6c8d0df1f542c5516f7534e82cb97

Summary:
[Folly] An intro to the upgrade mutex in the `Synchronized` docs.

Describes what the upgrade mutex is. Extends the existing docs which describe `Synchronized` and `LockPtr` interface and behavior in the presence of an upgrade mutex.

Reviewed By: snarkmaster, simpkins

Differential Revision: D3746177

fbshipit-source-id: 68b0570a36cc1f4393d5ccca535efa02752ca11d

Summary: Lets the kernel choose the port instead of hardcoding it.

Reviewed By: djwatson

Differential Revision: D3745911

fbshipit-source-id: d9680ec286e8015abb9274c30b572ff1d91548ce

Summary: [Folly] Remove a dead comment in `folly/test/SynchronizedTest.cpp`.

Reviewed By: simpkins

Differential Revision: D3745609

fbshipit-source-id: acdbd3eaa6d947213b72fe13cec0291545a60c87

Summary: Because it, and a whole bunch of other things, are used in the header but not properly included.

Reviewed By: yfeldblum

Differential Revision: D3744653

fbshipit-source-id: c10dbb83109200b6186b8ed5ef0d2447d4200f69

Summary: Well, the explicit instantion for it anyways. The extern template declaration for it declares it as `noexcept`, so MSVC generates an error because the explicit instantiation is not also marked as `noexcept`

Reviewed By: yfeldblum, ericniebler

Differential Revision: D3744090

fbshipit-source-id: 4e756b2761c23a436097a6131b9b2ecd59faf4f9

Summary: Because it is a portability header, but was created before portability headers were cool.

Reviewed By: mzlee

Differential Revision: D3743475

fbshipit-source-id: 5d2fe23ce08f0425ce48b4871fa660e69f57cc39

Summary:
This diff updates the documentation for folly::Synchronized to include
upgradable locking

Reviewed By: yfeldblum

Differential Revision: D3740983

fbshipit-source-id: d201fcfa6f62ce168125d2a9caa096e079446efa

Summary: Make strict mode stricter, by not allowing singleton to be fetched after shutdown (even with try_get).

Reviewed By: yfeldblum

Differential Revision: D3737925

fbshipit-source-id: 8d5536c4f27e13feee722b5abeb15db6fe3d77bf

Summary: This diff adds support for upgradeable locks to folly::Synchronized

Reviewed By: yfeldblum

Differential Revision: D3683205

fbshipit-source-id: 1b91ab07076566b4e5b535f2a2dbe1c8d9f3d1c2

Summary:
Depends on D3718573 and the other diff to sync tp2 on fbcode after D3718573
lands.

This adds the PRI flag for using on EPOLLPRI events. The test makes a
server/client and client a MSG_OOB message to make it appear as a priority
event.

Masked under a preprocessor directive until libevent upstreams the patch that I
will send for 2.0

Reviewed By: djwatson

Differential Revision: D3722009

fbshipit-source-id: c15233d4739a38092d11c3026c483c7a9c8e5dac

Summary:
There are 3 separate issues that this addresses to get Expected working correctly under MSVC.
The first is simply that it doesn't like `StrictConjunction`. Switching that to `std::conjunction`, which is part of C++17 and already implemented in MSVC, solves that issue.
The second is that MSVC was complaining that all members must be initialized in a `constexpr` constructor, but only one of the base classes of `ExpectedStorage` was being initialized, and, as there were no default `constexpr` constructors for the other bases, they couldn't be initialized. This was solved by making the base class's default constructors `constexpr`.
The last was the most fun, as the simple solutions all resulted in internal compiler errors. MSVC doesn't like SFINAE evaluation in the context of a template type parameter on a static operator defined inline in the class via `friend`. The solution is to simply move the definitions after the class and only include the declarations to be able to mark them as `friend`.

Reviewed By: ericniebler

Differential Revision: D3731833

fbshipit-source-id: ea9244b247b69046866f27cee9fdbd1b2405cafb

Summary:
Use a bitmap search to find the next wheel timer tick instead of a linear scan.
Need to store the current bitmap bit in the individual timeout to support cancellation.

Given the WHEEL_SIZE of 256, this will reduce to 4 ffsl/cmov instructions.

Reviewed By: yfeldblum

Differential Revision: D3637116

fbshipit-source-id: 1a37e19a5342604ec81735eaf85b72b6f673ea1e

Summary:
Preciesly calculate the next tick.  Currently only calculates the tick based on the lowest level of wheel timer, so it will still tick at least every WHEEL_SIZE intervals.

Currently the tick calculation is a linear scan over all the buckets, the next diff will optimize this.

Reviewed By: yfeldblum

Differential Revision: D3637096

fbshipit-source-id: 53dd596a2085c05c657cccbc7efba267bbd086a6

Summary: Because we need to translate them between sockets and file descriptors when we're on Windows.

Reviewed By: yfeldblum

Differential Revision: D3724802

fbshipit-source-id: 07fff6e1bec7b9b90e0d39fd98441466a746b7f7

Summary: Started failing when we turned on unused-result errors.

Reviewed By: yfeldblum

Differential Revision: D3728565

fbshipit-source-id: b12aee8d99f725f1a1cfaf30e9afa66bd05f7989

Summary: Split up the big, all-inclusive Portability header a bit

Reviewed By: yfeldblum

Differential Revision: D3723253

fbshipit-source-id: a91c38775825626f3c13853ac8168daa078a169a

Summary:
It looks like we were effectively avoiding short-circuiting callbacks submitted for execution in primary event-base (evb == nulptr). The check was there, but it was never effective, since on `addAcceptCallback` we would mask the `nullptr` with our event base pointer.

I see two ways to fix that: either modify the check

    if (info->eventBase == nullptr) { ...} on line 834

to compare to the presently attached event base, or store `eventBase = nullptr` into callbacks_ list (CallbackInfo struct). The second approach requires more changes (implemented here) but allows the caller to still submit callbacks for execution via notification queue event in primary event base by supplying eventBase parameter != nullptr in addAcceptCallback. I therefore chose the second approach.

The existing unit-tests needed modification to avoid using the "broken" nullptr semantics (most cases were assuming it would be using notification queue signaling). I quickly looked at fbcode, and it looks like we only have a few cases of addAcceptCallback() with nullptr, the unit-tests for those are passing.

NOTE: The removeAcceptCallback() semantics is different with regards to eventBase; nullptr here means "scan all callbacks regardless of event-base they belong to".

Reviewed By: djwatson

Differential Revision: D3714697

fbshipit-source-id: 2362bcff86a7e0604914b1cb7f1471fe4d03e78e

Summary:
If we fallback from SSL to TFO and the connection times
out, invokeConnectSuccess tries to deliver the connectError,
however we've already delivered the connect callback to the user.

This is bad because we have no way of reporting an error back.
This changes it so that when using SSL and we're scheduling a timeout
when we're falling back, we will schedule a timeout of our own which
will invoke AsyncSSLSocket's timeoutExpired. This will return a handshakeError
instead to the client.

Reviewed By: yfeldblum

Differential Revision: D3708699

fbshipit-source-id: 41fe668f00972c0875bb0318c6a6de863d3ab8f9

Summary:
Handle handshake timestamps and timeouts when TFO
is used.

If we fallback from TFO to connects, we should unset
the handshake timeout.

When we restart the handshake, we should reset the handshake
timeout and also reset the timestamps of the connection.

Reviewed By: yfeldblum, djwatson

Differential Revision: D3708660

fbshipit-source-id: 960030ca14d9f1cc8cb83059491ceffe6ba8f2ed

Summary:
We currently call handleInitialReadWrite.
The reason for this is that if the read callback
was set before TFO was done with connecting, then
we need to call handleinitialreadwrite to setup the
read callback similar to how connect invokes handleInitialReadWrite
after it's done.

However handleinitalreadwrite may also call handleWrite
if writeReqHead_ is non null.
Practically this will not happen since TFO will happen on
the first write only where writeReqHead_ will be null.

The current code path though is a little bit complicated.
This simplfies the code so that we dont need to potentially
call handleWrite within a write call.

We schedule the initial readwrite call asynchrously.
The reason for this is that handleReadWrite can actually fail if updating
events fails. This might cause weird state issues once it returns and we
have no mechanism of processing it.

Reviewed By: djwatson

Differential Revision: D3695925

fbshipit-source-id: 72e19a9e1802caa14e872e05a5cd9bf4e34c5e7d

Summary:
This is a basic implementation of a new Observer API. I mostly see this being useful as a replacement for various configuration subscription APIs (Configerator, SMC etc.)

The library provides an Observer primitive. At any time user can take a Snapshot of data in the Observer (which is a view with the most recent version of the data). New Observer can be created by providing a generator functor. Such Observer mays depend on other Observers and its generator functor is re-run automatically every time, when at least one of the dependencies are updated. The implementation may also ignore intermediate updates and will only use the most recent version of other Observers, when re-computing Observer data.

Reviewed By: yfeldblum

Differential Revision: D3481231

fbshipit-source-id: 96c165f8081cff0141d5814ec2bc88adeb2e1e74

Summary: And clean up the extra main.cpp

Reviewed By: yfeldblum

Differential Revision: D3717445

fbshipit-source-id: 2a5d554824c454b5339514d0d4ca7ae9474abdb9

Summary:
The current implementation didn't work for MSVC, as it tries to evaluate `noexcept` expressions in base class lists before the template is instantiated.
`std::is_nothrow_swappable` is coming in C++17, and MSVC already has it, so use it instead.

Reviewed By: yfeldblum

Differential Revision: D3724399

fbshipit-source-id: 7927584618a7870824b2e7242fcae562647f4ef4

Summary:
This change adds a non-throwing interface for folly::to<T>: tryTo<T>, which
returns an Expected<T, ConversionCode>.

Here is how the non-throwing interface compares to the regular interface in
terms of performance. On the successful path, there's generally not much
difference between using the throwing and non-throwing interfaces. For the
error path, tryTo<> is about three orders of magnitude faster than to<>.

Reviewed By: mhx

Differential Revision: D3720512

fbshipit-source-id: dadb8db1b7d7ad8d3e80c1cc69c0480169f9217a

Summary:
Using boost intrusive member hooks in complex inheritence heirarchies under MSVC is [unsupported](http://www.boost.org/doc/libs/1_61_0/doc/html/intrusive/usage.html#intrusive.usage.usage_member_hook), and, in combination with a [regression in VS 2015 Update 2](https://connect.microsoft.com/VisualStudio/Feedback/Details/2555433) that is not fixed in Update 3, the async socket tests that use this compile under MSVC, but fail at runtime because the hook pointer ends up pointing at the node's vtable rather than the hook.
This just works around the issue by using a base hook instead.

Reviewed By: djwatson

Differential Revision: D3724521

fbshipit-source-id: a55e36a2e79a15d9943b6090f6194fd480e19074

Summary: These tests will always fail if we're building against a version of OpenSSL that doesn't have the extension.

Reviewed By: anirudhvr

Differential Revision: D3724893

fbshipit-source-id: a093d62b9b5ea8239b5d52a66da2a833911b4f47

Summary: Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70983

Reviewed By: mhx, spacedentist

Differential Revision: D3724410

fbshipit-source-id: 692b1c1f49211a4170900505339794f09cec2369

Summary: Orvid noticed this was always throwing on a properly formated client hello, since the sig algs extension length isn't subtracted from the counter. This doesn't actually affect any behavior (except possibly a slight perf hit), but is pretty clowny.

Reviewed By: anirudhvr

Differential Revision: D3722887

fbshipit-source-id: 579993caac96da24fb567ab977b09fca519750a0

Summary:
This diff adds folly::partial, a function to partially apply
a set of zero or more arguments to a callable. It is similar
to Python's `functools.partial`.

`folly::partial` takes a callable object and additional
arguments and returns a callable with those additional
arguments bound to it. When the returned callable is invoked
with additional arguments, those are appended to the set of
arguments that were passed to `folly::partial`.

It is similar to `std::bind`, but more simple as it does not
support reordering of parameters, but also does not
require you to know how many arguments will be
eventually passed to the callable. Also, `std::bind`
does not support move-only types being passed by-value.
`folly::partial` does:

  void someFunc(std::unique_ptr<Foo>, int);
  auto p = folly::partial(&someFunc, std::move(foo_unique_ptr));
  ...
  std::move(p)(42);

Reviewed By: mhx

Differential Revision: D3252539

fbshipit-source-id: ee093771ac732fa70052b9908dcb75e90ba80efe