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

Summary:
Because apparently I didn't actually add the `Windows.h` include when I added support for MSVC.
This is safe for all platforms because the portability header only includes `Windows.h` when compiling on Windows.

Reviewed By: yfeldblum

Differential Revision: D3347785

fbshipit-source-id: 4f3e4e6c11953e2588b6fed287324a92e3ef8873

Summary: Apparently I failed to accurately transfer this particular change to fbcode, which meant it didn't actually compile on Windows.

Reviewed By: yfeldblum

Differential Revision: D3347976

fbshipit-source-id: 775682f10ab68672f6463ccc69a222ae0a52a097

Summary:
The existing Cursor::peek() method pre-dates the existence of folly::ByteRange,
and so it returns a std::pair containing a pointer and length.  This is usually
more awkward to use than ByteRange.

This adds a peekBytes() method that returns a ByteRange object, and updates all
users of peek() in folly to use peekBytes() instead.  Eventually I think we
should add a FOLLY_DEPRECATED attribute to peek().  I will wait to add this tag
until after converting a few other projects to use peekBytes(), though.

Reviewed By: alandau

Differential Revision: D3337302

fbshipit-source-id: 14220a059d915bf5adc66b8b283f7228b796a4dc

Summary:
We should use folly::make_unique instead of std::make_unique in order to support
compilers without support for C++14.

Reviewed By: pavlo-fb

Differential Revision: D3343288

fbshipit-source-id: 9150af752e57988962a7580851ffa32086c669d7

Summary: MSVC is a massive pain in this respect, and, after testing many workarounds, and only ending up with it just emitting a dynamic initializer for them, it's easier to just generate the table as a `uint64_t` and load it explicitly.

Reviewed By: yfeldblum

Differential Revision: D3270226

fbshipit-source-id: 77bc84e58d393373de05a28a30dcb80b66c09c9f

Summary:
If a TemporaryDirectory with scope DELETE_ON_DESTRUCTION gets moved
and then goes out of scope, the directory will be deleted while the moved
object still holds that path; we just clear the path from the old object to
prevent this

Reviewed By: yfeldblum

Differential Revision: D3331079

fbshipit-source-id: 9c99413661e2436ccec937d3fa652da810133b34

Summary:
As part of my campaign to get `HHWheelTimer` away from intrusive ref-counting semantics, (cf. D3237530), I am redefining `HHWheelTimer::SharedPtr`. It is now a true `std::shared_ptr`. This will break clients that attempt the following:

  HHWheelTimer::UniquePtr timer1{HHWheelTimer::newTimer()};
  HHWheelTimer::SharedPtr timer2{timer1};

In the past, that code would compile, because `timer2` could use the intrusive ref-counting, and `timer1` would still be valid. After this change, the second timer would need to be initialized with `std::move(timer1)` instead. The `UniquePtr` is starting to actually be unique.

There is only one place in the code that actually tries to do such a copy. It's in a test, which I have changed. Any other instances of that behavior would create a compilation error, so it's impossible for one to be overlooked.

Reviewed By: djwatson

Differential Revision: D3337038

fbshipit-source-id: 085e4da41c9a142d253a1ac0b1dd0fc508dff704

Summary: Actually __assume when we assume.

Reviewed By: meyering

Differential Revision: D3336033

fbshipit-source-id: 6c931e9f832dd1d861d03e3ad8e308f612522401

Summary:
[Folly] Avoid `std::initializer_list` ctor in `folly::dynamic::array`.

This will help deprecate the dangerous initializer-list constructor. The init-list construction is dangerous because its semantics vary by compiler and by compiler version.

Reviewed By: ot

Differential Revision: D3333148

fbshipit-source-id: 031e7593b7e28b299d5eeeb5ce7aed9216dd3a5c

Summary:
LoopKeepAlive handle can be grabbed to signal that some external event will later be scheduled on the EventBase via runInEventBaseThread. Usually the code which will be calling runInEventBaseThread only has a raw pointer to an EventBase, so it doesn't have any way to know it was destroyed.

This change ensures that EventBase destructor will keep running the event loop until all such LoopKeepAlive handles are released.

Reviewed By: yfeldblum

Differential Revision: D3323835

fbshipit-source-id: 4071dae691a61dfebe2f1759cf99f661b161fa4a

Summary:
The configure script doesn't define `FOLLY_HAVE_PREADV` if `preadv` isn't supported, so these checks were wrong. Undefined defines expand to `0`, so this is safe.
Fixes https://github.com/facebook/folly/issues/412

Reviewed By: mzlee, yfeldblum

Differential Revision: D3329405

fbshipit-source-id: faee8951c68d4c67e06e7720dfc142e63a9dbd9f

Summary:
This diff templates folly::fibers::await by Baton.
This would be helpful in passing in custom BatonType's, which is needed for D3007734

Depends on: D3314891

Reviewed By: andriigrynenko

Differential Revision: D3314925

fbshipit-source-id: 9052dc503b9509f16cd41b5e3ede0479a98067aa

Summary:
The current use case of `std::memory_order_consume` in this project was intended to provide the appropriate synchronization in cases where a consumer spins on `while( spsc_queue.empty() ) {} `, and then attempts to use an element of the queue since the loop was broken out of, according to comments [here](https://reviews.facebook.net/D48141). Consume semantics do not provide this guarantee according to the standard since there is no data dependency from the producer that can be carried to the consumer by doing a load-consume from the corresponding functions. What is needed is a load-acquire. Current compilers promote `memory_order_consume` to `memory_order_acquire`. Thus, this example appears to work simply due to the promotion from consume to acquire, but would fail to generate the right synchronization instructions on weaker architectures once `memory_order_consume` is implemented as intended.  Therefore, the `memory_order` should be tightened to `memory_order_acquire` to guarantee visibility to the consumer
Closes https://github.com/facebook/folly/pull/381

Reviewed By: djwatson

Differential Revision: D3173574

Pulled By: nbronson

fbshipit-source-id: b109be2e74f016750a3fe1f848e3fc66e609b9d2

Summary:
[Folly] Extract `Try` to top-level.

It was in `folly/futures/`, but this diff moves it to `folly/`.

It is needed for futures, but it is are more general than futures and can be used separately.

Use `folly/Try.h` instead of `folly/futures/Try.h`.

Also fixes up all `#include` sites:

    hg grep -lw folly/futures/Try | xargs perl -pi -e 's,\bfolly/futures/Try\b,folly/Try,g'

Reviewed By: markisaa

Differential Revision: D3309908

fbshipit-source-id: cdf13f0ac0b0e36aa07e0f1d04870d06500c5874