Summary:
This adds TFO support to AsyncSSLSocket which
uses the support for TFO from AsyncSocket.

Because of the way AsyncSSLSocket inherits from
AsyncSocket it is tricky.

The following changes were made:
1. Openssl internally will treat only errors with return
code -1 as READ_REQUIRED or WRITE_REQUIRED errors. So this
diff changes the return value of the errors in the TFO fallback
cases to -1.

2. In case we fallback after SSL_connect() to a normal connect,
we would have to restart the connection process after connect
succeeds. To do this this overrides the connection success callback
and restarts the connection before sending the callback to AsyncSocket
because sometimes callbacks might synchronously call sslConn() in the
normal connect cases.

3. Delegated bioWrite to call sendSocketMessage instead of sendmsg directly.

Reviewed By: djwatson

Differential Revision: D3391735

fbshipit-source-id: 61434f6de4a9c3d03973c9ab9e51eb49e751e5cf

Summary:
This defines the macro `FOLLY_SANITIZE_THREAD`, similar to `FOLLY_SANITIZE_ADDRESS`.

Note that gcc *just* landed support for the `__SANITIZE_THREAD__` macro two weeks
ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354

Reviewed By: igorsugak

Differential Revision: D3389021

fbshipit-source-id: df6497a7741657c297ee812ed07cbae102b6810d

Summary: Attempting to use this under MSVC, as `MemoryIdler::defaultIdleTimeout` does, generated warnings about the symbol being dynamically initialized due to an implementation limation. Solve this by defining a union instead of calling `encode` in the constructor.

Reviewed By: yfeldblum

Differential Revision: D3387916

fbshipit-source-id: b0d628b6d086960e94121b6183a31348fb151aac

Summary: MSVC is warning that `client` may be uninitialized, which is possible if the callback doesn't actually set them for some reason. Solve that by explicitly initializing it to `nullptr`. Also deal with the warning about the initialization of `dynamic::array` using braced syntax by not using that syntax.

Reviewed By: yfeldblum

Differential Revision: D3387782

fbshipit-source-id: e4d25ad32e99a73d7d062be9a2f2b5bde5d17396

Summary: The first is both wrong (due to the difference in semantics) and unneeded, as MSVC 2015 supports `snprintf` natively and with the correct semantics. The second is simply never used.

Reviewed By: yfeldblum

Differential Revision: D3387551

fbshipit-source-id: ea666a60ce859a59ad3d3ff961b4d7d642fd86eb

Summary: GuardPageAllocator now keeps a track of all protected pages. If SIGSEGV occurs, signal handler can check address at fault against protected pages and if it matches - we got a fiber stack overflow.

Reviewed By: yfeldblum

Differential Revision: D3386960

fbshipit-source-id: 775b36ee08fecbbd87da0025f794717c222f5cce

Summary:
Always overriding write bio method
allows us to more cleanly implement
features like eor tracking, support
multiple ssl libraries, and also TFO

Reviewed By: anirudhvr

Differential Revision: D3350482

fbshipit-source-id: ddd2333431f9d636d69c8325b2c18d7cc043b848

Summary: use std=c++1y for compiling since we use c+=14 feautures but don't want to require a recent gcc.

Reviewed By: bhamiltoncx

Differential Revision: D3380287

fbshipit-source-id: 8ece6007cf613d307bafe692f1af70f5359df95a

Summary: Because if it's not, all hell will break lose (apparently).

Reviewed By: meyering

Differential Revision: D3373061

fbshipit-source-id: f08a863d1bacadeeff9d9cea041f399f136cfc74

Summary: As the (now removed) comment says, GCC 4.6 doesn't treat structs with private members as POD types... The thing is, GCC 4.6 is long dead, so make `data_` private and assert that it's a POD type.

Reviewed By: meyering

Differential Revision: D3373172

fbshipit-source-id: b2f1ee59d544461fe986705164cc6c866af62865

Summary:
The Folly `make check` build is broken with Clang on OS X.

This diff fixes the following break in `test/SynchronizedTest.cpp`:

  SynchronizedTest.cpp:150:10: error: thread-local storage is not supported for the current target
    static thread_local int lockCount_;

The problem is clang on OS X doesn't support the `thread_local` extension:

http://stackoverflow.com/a/29929949

so we now use the `FOLLY_TLS` compatibility macro.

When I fixed this, I found the test also failed to compile if `FOLLY_SYNCHRONIZED_HAVE_TIMED_MUTEXES` was `#define`d to `0` (as it is on OS X), so I fixed that.

Reviewed By: mzlee

Differential Revision: D3361215

fbshipit-source-id: e93be6872bcab03090448b9421e502e472f149ff

Summary: It's simply not possible to compile the C++ side of the C API as C, so don't guard the `extern "C"` as if it is.

Reviewed By: meyering, yfeldblum

Differential Revision: D3369474

fbshipit-source-id: d3316704ce17a471bc9d6a3a235472bf40cedb9d

Summary: Add methods to change cipher suite list and sigalg list

Reviewed By: anirudhvr

Differential Revision: D3295935

fbshipit-source-id: eb46311986465e399eafa69e3070b53b36bce820

Summary: Include cerrno to define `EOPNOTSUPP` and `ENOPROTOOPT`.

Reviewed By: elindsey

Differential Revision: D3366479

fbshipit-source-id: 3a93a1c247ffa4a9d4ea03577713362a2a35c8b7

Summary: Remove it as we do not need it here.

Reviewed By: yfeldblum

Differential Revision: D3365991

fbshipit-source-id: bb36caca0319df4c8d6e3d978045b7c28369f043

Summary:
This adds support to establish connections
over TFO.

The API introduced here retains the same
connect() + write() api that clients currently
use.

If enableTFO() is called then the connect will
be deferred to the first write. This only works
with request response protocols since a write
must trigger the connect. There is a tradeoff here
for the simpler API, and we can address this with
other signals such as a short timeout in the future.

Even though the client might enable TFO, the program
might run on machines without TFO support.
There were 2 choices for supporting machines where
TFO might not be enabled:
1. Fallback to normal connect if tfo sendmsg fails
2. Check tfo supported on the machine before using it

Both these have their tradeoffs, however option 1 does
not require us to read from procfs in the common code
path.

Reviewed By: Orvid

Differential Revision: D3327480

fbshipit-source-id: 9ac3a0c7ad2d206b158fdc305641fedbd93aa44d

Summary:
Diff #14 of 14.

This just switches the includes of the headers, it does not make the adjustments actually required to work for MSVC.

Reviewed By: mzlee

Differential Revision: D3249009

fbshipit-source-id: 434f58a7b8f4d0b7d142bc6a4abed8d95c953a7f

Summary: Diff #13 of 14.

Reviewed By: mzlee

Differential Revision: D3116264

fbshipit-source-id: 80e498b7062f40d723e156901bf62a2101a6e6ba

Summary: Diff #12 of 14.

Reviewed By: mzlee

Differential Revision: D3187000

fbshipit-source-id: ad56ca8ff20fa88949554b61545ee1bf982b0569

Summary: Diff #11 of 14.

Reviewed By: mzlee

Differential Revision: D3262478

fbshipit-source-id: d06eee44d1ccefc78a381e44c400c0242b5e0e5a

Summary: Diff #10 of 14

Reviewed By: mzlee

Differential Revision: D3270909

fbshipit-source-id: 2c644ca5db4ecf0387b167d2f6ecc62ddf687a56

Summary: Diff #9 of 14.

Reviewed By: mzlee

Differential Revision: D3262436

fbshipit-source-id: 60c5df03e91163c651bc6e5e0d38ba8b46b8c723

Summary: Diff #8 of 14.

Reviewed By: mzlee

Differential Revision: D3186943

fbshipit-source-id: 3b631faac36f3ec6e7fce031f07d8a98c76d7908

Summary: Diff #5 of 14.

Reviewed By: mzlee

Differential Revision: D3186885

fbshipit-source-id: 1947656137cad62a019cdf687cff9913bcecde2a

Summary: Diff #4 of 14.

Reviewed By: mzlee

Differential Revision: D3181101

fbshipit-source-id: d0db67ae19ee71e6a251c299ef672baead3ab9d9

Summary: Diff #3 of 14.

Reviewed By: mzlee

Differential Revision: D3110299

fbshipit-source-id: 39e4980df14b0b108b20dbbe57f2c5c6b361ea2e

Summary: Diff #2 of 14.

Reviewed By: mzlee

Differential Revision: D3115972

fbshipit-source-id: c75cbc95f37e8f2c2bf81311a8ca08ee766fc107

Summary:
This changes includes of `<sys/time.h>` to `<folly/portability/SysTime.h>`.

The ultimate goal of all of this is to get HHVM compiling on Windows with MSVC 2015. At the moment there are no plans to support MCRouter, Squangle, or AFDT under Windows. There are also no current plans to support MinGW or Cygwin.

Now, on to the headers themselves. There are three primary kinds of portability headers.

  - Replacement headers. These are headers such as `<sys/time.h>` that MSVC simply does not have. These headers should always be included instead of the headers they are replacing.
  - Additive headers. These are headers, such as `<time.h>` that MSVC has, but are either missing functions, or has the functions but under a different name. The portability headers for these only needs to be included instead of the original header if you are using a function that MSVC does not have. The reason for this is that forcing the use of the portability header for `<stdlib.h>` just because MSVC doesn't have `mkdtemp` and `realpath` would just be messy.
  - Utility headers. These are portability headers, such as `Memory.h` that exist to provide a portable interface to various things, in this case the allocation and freeing of aligned memory. They are not implementing any existing API, and all contents are in the `folly` namespace.

The API's implemented in the first and second types of headers are intended as drop-in replacements for the Linux versions, however they only implement the functions and features that are actually needed, and are not intended as feature-complete replacements. They are not intended for use outside of Facebook projects. Any API's expecting text input expect them to be in the same encoding as the Posix API's define, in most cases that means UTF-8. Anywhere in the portability headers that fails to account for this is a bug, and should be pointed out in the diff (if it's still in review), or else by filing a task detailing the issue and assigning it to me.

For all headers, if there is a mechanism in C++11, or else in Folly itself, that allows the same functionality, that mechanism should be used instead of adding a function to the portability headers.

Reviewed By: swtaarrs, yfeldblum

Differential Revision: D3095643

fbshipit-source-id: 3a5c0029f95b03ea320725df88e14a67ca38a445

Summary:
Add generic functions for reading or skipping until a predicate check fails.
This will allow us to simplify a few different call sites that have their own
logic similar to this.  Also change readTerminatedString() to use
readWhile().

Reviewed By: alandau

Differential Revision: D3337581

fbshipit-source-id: 9f50914c83adfc882219046862972661bed0e72a

Summary:
The Folly `make check` build is broken with Clang on OS X.

This diff fixes the following break in `test/ProducerConsumerQueueTest.cpp`:

  In file included from ProducerConsumerQueueTest.cpp:17:
  ../../folly/ProducerConsumerQueue.h:55:18: error: no member named 'bad_alloc' in namespace 'std'
        throw std::bad_alloc();

The problem is a missing `#include <memory>` in `folly/ProducerConsumerQueue.h`.

Reviewed By: djwatson

Differential Revision: D3361252

fbshipit-source-id: d740914f54ede5617abc16437ab2e20a7376f6e5

Summary:
The Folly `make check` build is broken with Clang on OS X.

This diff fixes two breaks in `test/FunctionTest.cpp`:

1. `FunctionTest.cpp:39:20: error: implicit instantiation of undefined template 'std::__1::array<int, 100>'`
2. `FunctionTest.cpp:103:3: error: no matching conversion for functional-style cast from 'Function<int (int)>' to '::testing::AssertionResult'`

The first was a missing `#include <array>`, and the second is a workaround for this gtest bug:
https://github.com/google/googletest/issues/429

Reviewed By: djwatson

Differential Revision: D3361188

fbshipit-source-id: 8140de978a2cbaf0f4aab45781ce0d656f03202b

Summary:
The Folly `make check` build is broken with Clang on OS X.

This diff fixes the following break in `make check`:

  make[3]: *** No rule to make target `../futures/test/ThreadedExecutorTest.cpp', needed by `../futures/test/ThreadedExecutorTest.o'.  Stop.

The problem is a reference to a file which was moved to `wangle` in D3286988.

Reviewed By: simpkins

Differential Revision: D3361287

fbshipit-source-id: a9ae794374982b4accf806bd9608988430c75cfd

Summary: AsyncSocket::handleWrite may trigger HTTPSession::onWriteSuccess which may totally delete the HTTPSession. AsyncSocket::handleWrite also calls bufferCallback_->onEgressBufferCleared(). That bufferCallback_ is the HTTPSession. So in this diff resets bufferCallback_ to nullptr upon HTTPSession shutdown. afrind had a suggestion of adding a DestructorGuard in AsyncSocket::handleWrite. But i don't know DestructorGuard that well. I think it will keep AsyncSocket from being deleted but not the HTTPSession? Or maybe I can DestructorGuard dg(bufferCallback_) ?

Reviewed By: afrind

Differential Revision: D3311058

fbshipit-source-id: cdb5fcbd53837a3effbc096eab87fca4e5d17291

Summary:
Min rto is now 50ms, so change the
test accordingly

Reviewed By: w-o-o

Differential Revision: D3357140

fbshipit-source-id: 5a807fabc1a3c216a5120b8eb4930e5c1eb52b7a

Summary:
Contrary to the other `append` flavors, `fbstring::append(size_type n, value_type c)`
does not use exponential growth, which can trigger quadratic behavior.

Reviewed By: philippv

Differential Revision: D3357315

fbshipit-source-id: 2301ed1a9953544368663107113890a25c6621ae

Summary:
MSVC generates warnings if you define multiple assignment operators or multiple copy constructors on the same type. This is deliberate in `folly::Function`, so just disable the warnings for the struct instead.
Note that the warnings have to be disabled for the entire struct for them to actually be disabled. Disabling them just around the declarations of the constructors and operators in question does not actually disable the warnings.

Reviewed By: yfeldblum

Differential Revision: D3347746

fbshipit-source-id: abb53a1e62bcfb7ce02759a7ce8637d824a82081

Summary:
The two function definitions in this file are both normal function definitions,
not template functions.  Therefore this should be just a normal .cpp file, and
not a -defs.h header file.

Reviewed By: igorsugak

Differential Revision: D3348439

fbshipit-source-id: 3ebe49c84493f5aab06c568d9df15a37c2c48836

Summary:
The default constructor creates the Subprocess in an uninitialized state.  This
makes it possible to default-construct a Subprocess, but only initialize it
later using the move assignment operator.

Even before this diff, it was possible to have Subprocess objects in
uninitialized states after using the move assignment operator to move the data
out of a Subprocess object.

Reviewed By: yfeldblum

Differential Revision: D3348490

fbshipit-source-id: aa6acef9be770de8f0ee118da294cb134f04a466

Summary: There is no equivalent functionality for Windows, so disable it completely.

Reviewed By: andriigrynenko

Differential Revision: D3348481

fbshipit-source-id: 52a104f5a8013113f54d5b10c2f0f9b720eeb4f6

Summary: Because, as MSVC rightly tells us, it's not actually defined anywhere.

Reviewed By: yfeldblum

Differential Revision: D3347654

fbshipit-source-id: 2162bc745136ee0129caa4de78f38e1361083cd1