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

Summary:
[Folly] `ScopedBoundPort`.

An RAII class for `bind`ing, but not `listen`ing, an ephemral port.

Useful when there is a need to test server-down cases - in such cases, a guaranteed-not-listening port is required.

Extracted from a unit-test in Thrift; switches the Thrift test to use this extracted implementation instead.

Reviewed By: djwatson

Differential Revision: D3714293

fbshipit-source-id: 649fba1a0b7f0519b8297a3183d03c5dde23ddc6

Summary:
Because MSVC didn't like the new version used to add support for multiple tuples.
This also switches to std::index_sequence rather than our own home-grown version.

Reviewed By: yfeldblum

Differential Revision: D3706506

fbshipit-source-id: 724c995fe2671d21f78cd7ffa4b19ea1b278c308

Summary:
[Folly] Let `FOLLY_SAFE_DCHECK` be erased by the optimizer in release builds.

Just like `DCHECK` is erased by the optimizer, not by the preprocessor, in release builds. `assert`, by contrast, is erased by the preprocessor. But the intention here is to mimic `DCHECK`.

This makes a difference if the expression uses a parameter or local variable. This way, the AST still sees a use of that parameter or local variable in release builds (the optimizer later removes that use). Rather than the AST not seeing any uses of that parameter or local variable, and consequently the compiler emitting a warning or error that the parameter or local variable is unused.

Even so, the expression is never evaluated in release builds. We ensure that by actually using `true || (expr)` as the conditional of our expanded expression in release builds. The `true` comes from `!folly::kIsDebug`, which is a `constexpr bool` expression and is `true` in release builds. The `||` short-circuits; the optimizer sees that the whole expanded expression statically evaluates to `static_cast<void>(0)` and removes it the expanded expression entirely.

Reviewed By: simpkins

Differential Revision: D3701227

fbshipit-source-id: e4fa48ee5a88e45dc08757c14d1944de734796ff

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: D3557832

fbshipit-source-id: 21f06b3c1a72b06dcf867ed3a3410f51e0fdaf45

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: D3557832

fbshipit-source-id: 25b29834b6fda474a7cdd43a7dea69ff4ee183c8

Summary: instead fetch it only on exception

Reviewed By: andriigrynenko

Differential Revision: D3718303

fbshipit-source-id: a021d150f20ab00fe8146f17b19a69fa0da2b0da

Summary:
This is a workaround to an (already reported) bug in MSVC that results in it not considering the constructors of `dynamic` when attempting to construct the default value of a parameter if the type of the parameter is a universal reference.
It works by simply adding a pair of template specializations that cause MSVC to properly construct the default value.
This also removes the default value on the universal reference version, as the only things that should be using that overload now are non-dynamic values.

Reviewed By: yfeldblum

Differential Revision: D3704990

fbshipit-source-id: 7b85c4e48a1a1023bc2fe0a76a9632b11c4e9364

Summary:
Expected is like an Optional with extra state for reporting //why// the Expected is empty. Something like it is currently under review for inclusion in the C++ standard [1], and Andrei Alexandrescu has spoken about it [2]. It corresponds to the Either Monad in Haskell, where it is used as a return type of an API that has more than one failure mode.

By adding folly::Expected, we get a way to implement non-throwing APIs with a consistent and composable interface.

[^1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4015.pdf
[^2]: https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C

Reviewed By: mhx

Differential Revision: D3522501

fbshipit-source-id: 48b8ea2dfbd0769f26ec84d2d52fd41db75dc05a

Summary:
ApplyTupleTest.cpp was never added to Makefile.am. This commit fixes
that.

Reviewed By: yfeldblum

Differential Revision: D3715213

fbshipit-source-id: e1e914438d44affb6fe683614506338c3a3355c6

Summary:
Found this nit while trying to understand how fbvector works. 1) grwoing -> growing 2) remove that unnecessary "and"

Not sure about reviewers' choosing so I included the author and whoever phabricator suggested to me.

Reviewed By: meyering, yfeldblum

Differential Revision: D3714166

fbshipit-source-id: 8bf575c3f2954feb9e92611acd0aa23c5eee9a0a

Summary: Because it's a terrible idea. It also didn't work.

Reviewed By: yfeldblum

Differential Revision: D3711443

fbshipit-source-id: 48ab77dfff005347c72daeaf0d27390bb86f4bd1

Summary:
folly::NotificationQueue::tryConsume did not compile for
move-only types such as folly::Function. This diff fixes that.

Reviewed By: andriigrynenko

Differential Revision: D3711406

fbshipit-source-id: a52eba3eb31743165e4726f830f2a38d241f25a5

Summary:
A bunch of small changes that are necessary before we change
the definition of folly::Func from std::function<void()> to
folly::Function<void()>.

Reviewed By: yfeldblum, mzlee

Differential Revision: D3706210

fbshipit-source-id: 198d8a391ef6f545ad4411d316ba9e271ea795e3

Summary:
Changes discussed on the initial MicroLock diff, but that were
accidentally lost before commit.

Reviewed By: luciang, yfeldblum

Differential Revision: D3010789

fbshipit-source-id: 9538ebd1383d1561dd2ce210a2d05e342c6863e6

Summary: Because it doesn't need to be escaped, and MSVC will warn about invalid escape sequences. If being built with HHVM's settings for MSVC, it's actually an error, as the same warning is produced for multi-byte escape sequences in narrow strings.

Reviewed By: yfeldblum

Differential Revision: D3704596

fbshipit-source-id: 603e57a35f8b7433d1f6e47f4c2882244536b14f

Summary:
MSVC doesn't currently guarantee left-to-right argument evaluation order for values constructed via braced initializers, and produces a warning if you try to pass an argument with a non-trivial copy constructor by-value in a constructor used by the braced initializer.
This prevents the warning by simply accepting a const reference instead.

Reviewed By: yfeldblum

Differential Revision: D3705073

fbshipit-source-id: 917ec1bb776d6ec4bfefe50907d4c5ac2f2379b1

Summary: Some shuffling and elmination of other includes exposed the fact that this was calling the cpuid builtins, but hadn't included the header they were defined in.

Reviewed By: yfeldblum

Differential Revision: D3704321

fbshipit-source-id: 332c2d22714abaa74090abe7e7a5b28aec6b905a

Summary:
Winsock doesn't let you listen to a socket if it hasn't been bound to anything, so bind it to the port first.
TestServer was also never closing the file descriptor, causing the socket to leak.

Reviewed By: yfeldblum

Differential Revision: D3698467

fbshipit-source-id: cca415143009fbee99ebf94d7f46aedc9c59191d

Summary: Because they aren't currently constexpr under MSVC.

Reviewed By: yfeldblum

Differential Revision: D3705095

fbshipit-source-id: ea266ebd9677fb2ba232476160f7c10a23954db9

Summary: Because the tests are explicitly dependent on the size of these types, and `long` is a different size on Windows.

Reviewed By: yfeldblum

Differential Revision: D3704488

fbshipit-source-id: e15e95242c5e9c84165a50cfd2c3bc6e0d2e0c49

Summary: `<::` is a trigraph, which, although removed in C++17, MSVC still warns about the sequences (although it doesn't actually intepret them as trigraphs)

Reviewed By: yfeldblum

Differential Revision: D3704382

fbshipit-source-id: b093f854343db01bc166b1cc44763676fdd97a51

Summary:
Using _r_debug offers a number of benefits:
- It allows us to symbolize addresses in data segments like .bss that
  are marked "[heap]" in /proc/<pid>/maps.
- It requires a lot less code.

It also fixes a preexisting bug where we would fail to symbolize
addresses that fell in any section past the first in any position-
independent objects.  Since `elfFile->getBaseAddress()` should always
return 0 for any PIEs, we wouldn't correctly adjust the address to be
ELF-relative when performing symbol lookup.  (For the first section,
we just used the start of the range we found in /perf/<pid>/maps.)

There is a minor downside:
- We have to open an ELF header for each object in order to check if a
  given address is in the range of some segment.  Before, we used
  /proc/<pid>/maps to make the range check, and only opened the header
  once we knew it was the one we wanted.  In the common case, however,
  where the addresses are from our own executable, we don't open any
  more files than before (and, in fact, one fewer).

Reviewed By: luciang

Differential Revision: D3695872

fbshipit-source-id: 9bdcc77da4d658ffad5c671f9b8ea65a471ed64f

Summary:
[Folly] Remove `ConditionallyExistent`, because it violates the C++ spec.

The spec says that struct and class types occupy at least one byte. But the point of this class is to occupy zero bytes when the condition is false. That can't be made to work.

GCC and Clang support an extension allowing, in some cases, structs to occupy no space at all. But it violates the spec, and MSVC does not support the extension.

There is, sort of, the possibility of empty-base-class-optimization. But it will be very painful to use, and it will only work in some cases.

Since this is broken now, and fixing it would violate the C++ spec and break this under MSVC, it's better just to remove it.

Reviewed By: nbronson, Orvid

Differential Revision: D3696371

fbshipit-source-id: c475c6e15d9ff1bc4c44dc7e336ce74e6db640ef