Summary:
This was supposed to be the `Result` type, since it's called on the
Future returned by the lambda.

Test Plan: Added tests for void and different types in vector/lambda.

Reviewed By: mhl@fb.com

Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2087819

Tasks: 7126300

Signature: t1:2087819:1432142435:72914fa64eff03454774b87a24c426379defab3b

Blame Revision: rFBCODEf229322bc273190a85b5e995dcd8209b1fbf0825

Summary: This will allow a subsequent diff to implement file transfers as another type of write request

Test Plan: unit

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, folly-diffs@, yfeldblum, chalfant, fugalh, bmatheny

FB internal diff: D2080257

Signature: t1:2080257:1432044566:bcc0724d349879f46e3e58ee672aff7bf37fa5f6

Summary: Some of AtomicHashMap's locals shadow member functions - rename the locals to fix the warnings

Test Plan: unit tests

Reviewed By: chaoc@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant, tao-eng@

FB internal diff: D2086270

Signature: t1:2086270:1432083900:fae1be39e55e4c30b47fdc7a069bb13d75292b0a

Summary:
Subprocess doesn't have any non-movable members, and its implementation does not take addresses of the object, so I think it's safe. Move makes a bunch of code cleaner (you no longer have to wrap it in `std::unique_ptr` with associated clumsiness).

https://phabricator.fb.com/diffusion/FBCODE/browse/master/folly/Subprocess.h

Test Plan:
- unit test
- Searched for `this` in `Subprocess.{h,cpp}`.
- Inspected member variables: `pid_`, `returnCode_`, `pipes_`
- contbuild

Reviewed By: davejwatson@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2079167

Signature: t1:2079167:1432048688:26f96e29310298f47a9a9a7abef22dc863f68942

Summary:
The first file of Koans. Some simple constructor and `makeFuture` stuff, but this diff is mostly about the framework (ie the `TARGETS` and `main.cpp` and `Koan.h`, and the layout of the Koan files).

Known Issues: I am not nearly enlightened enough to write these in a particularly zen style with lots of inside zen-jokes, so I'm not even trying.

Test Plan:
Work through the koans,
then `fbmake runtests`,
reach enlightenment

Reviewed By: davejwatson@fb.com

Subscribers: cgthayer, exa, folly-diffs@, jsedgwick, yfeldblum, bmatheny, chalfant

FB internal diff: D2082141

Tasks: 6973057

Signature: t1:2082141:1432057657:273708f566154cc54f726b85f05457388357ef4e

Summary:
Add a getTotalCount() method to the Histogram class so that callers
can read out the number of values that were put into the histogram

Test Plan: Added a new test.

Reviewed By: simpkins@fb.com

Subscribers: net-systems@, evanmao, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2078239

Tasks: 7097793

Signature: t1:2078239:1431739799:5de3a02df67ff535e06b4a1547690440cf594824

Summary: Add a callback when a fiber becomes runnable

Test Plan: unit tests

Reviewed By: andrii@fb.com

Subscribers: alikhtarov, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2081306

Signature: t1:2081306:1432011152:0ee93cb2682eb2a289b99c403e91465e72dd4ee8

Summary: last pipeline in the original diff (HeaderServer/Client channel can also become pipeline stages in the future...)

Test Plan:
fbconfig -r thrift/lib/cpp2; fbmake runtests

canary results will follow in a comment

Reviewed By: alandau@fb.com

Subscribers: fugalh, folly-diffs@, chalfant, trunkagent, doug, alandau, bmatheny, jsedgwick, yfeldblum

FB internal diff: D2033559

Signature: t1:2033559:1430417432:c6cf4ccbf9ef26d89e7d7c5955d103348205b365

Summary:
See task. Set up a DAG of Future-returning tasks (optionally with executors) and eventually kick them off.
One big question is ownership. Currently the user would be responsible for ensuring that the FutureDAG outlives its own completion. This requirement could go away with shared_from_this magic maybe

Test Plan: unit. I didn't bother to test via() functionality because it's too much work for now - the functionality is trivial. Same for "true-async" dags...

Reviewed By: hans@fb.com

Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2073481

Signature: t1:2073481:1431961131:82a8898502d5308f6ab3cc8cc5b84b016d3998fe

Summary:
Yes, ideally we'd detect this at compile time, but if we can't, causing a SEV1
is not the best way to do it.

format() now behaves like formatChecked(); the old API is maintained for
backwards compatibility, but deprecated.

Test Plan: format_test

Reviewed By: simpkins@fb.com

Subscribers: trunkagent, dpittman, jdelong, sdmich, net-systems@, dmitri, folly-diffs@, yfeldblum, andrii, mssarang, chalfant

FB internal diff: D2075829

Tasks: 7095768

Signature: t1:2075829:1431713985:b3fdec4820104b4ddc4be0b6af999db174a692d9

Summary: Huge thanks to @afrind for debugging this issue with me and found the root cause. As per the comment from @afrind for the diff D1823407, there is a tricky race issue. The main thread could have left and reset the condition_variable from its stack but the EventBase thread tries to access it afterwards due to race and could be blocked indefinitely. This caused the server-side IO threads not able to pick up the incoming connections for the proxygen case. The fix is to use a simpler struct barrier and get a hold of the shared_ptr instead of the same object in a safer way.

Test Plan:
The original issue reproes very easily in HDFS XDC encryption case. Servers easily enter into bad state and we got high volume of timeouts from the client. With the fix, this does not happen anymore after the fix being deployed at 11:15PM. Here is the Scuba log before and after the fix:
https://fburl.com/109969805
And here is the correspond Scuba diagram for successful calls in the same test:
https://fburl.com/109971729
The throughput improved a lot after the fix.

Reviewed By: davejwatson@fb.com

Subscribers: doug, folly-diffs@, yfeldblum, chalfant, afrind, brettp, dougw, fma

FB internal diff: D2071646

Signature: t1:2071646:1431709609:10fb033536f9e4fb428dea8ba68f6a9a051616c0

Summary: PipelineBase needs something virtual so we can dynamic_cast from it down to the real pipeline, as we do in Proxy

Test Plan: built proxy with clang

Reviewed By: hans@fb.com

Subscribers: fugalh, mathieubaudet, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2075855

Tasks: 7077419, 7077417

Signature: t1:2075855:1431708780:03ce8d8f40cdb56d24baf75f4dc29004e5ea4c7a

Summary:
Use this if you don't need the order of the input, e.g. summing up
values. This constructs a separate Future chain to do the reducing,
because we don't want to add locking while reducing. The only lock
necessary is when adding a new Future to the chain, which should be
really quick.

Test Plan: Run all the tests.

Reviewed By: hans@fb.com

Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2015326

Tasks: 6025252

Signature: t1:2015326:1431557191:9ea2edccb0162dedf067b5b3300de2fe72a1a4c9

Summary:
If we make `chain` a member function we can avoid the type issues and infer everything. I also added thenMulti for symmetry. Sadly the compiler doesn't like having a thenMulti with an optional `Executor*` as the first argument, it fails after some deductions. Hence `thenMultiWithExecutor`.

itssobeautiful

Test Plan: Run all the tests.

Reviewed By: hans@fb.com

Subscribers: trunkagent, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2021000

Signature: t1:2021000:1431557618:169447dc9d747b23a8a1ba830e78c43713d09a96

Summary: `window` creates up to `n` Futures at a time and only starts new ones when previous ones complete. A sliding window.

Test Plan: Run all the tests.

Reviewed By: hans@fb.com

Subscribers: bmatheny, henryf, scottstraw, juliafu, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2015310

Signature: t1:2015310:1431557556:1017006cc9c9c2562ebe2c3dabfc4dbf316ff408

Summary:
I wish I could just have an add(Func, priority) but the damned overloaded virtual warnings become a nightmare, so it's addWithPriority.
I also switched priority to a uint8_t in the hopes of reducing Core size. Turns out std::atomic<uint8_t> is 8 bytes anyways :( I left it that way because come on you really shouldn't be using > 256 priorities.
Biggest problem is the data race with the two atomics executor_ and priority_. Should we just use a microspinlock to co-protect them? Could probably save some size from the atomics that way.

Test Plan: unit

Reviewed By: hans@fb.com

Subscribers: hannesr, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2039619

Tasks: 6928162

Signature: t1:2039619:1431551266:3b31ed2329301aaa9c32f0f41b6e61f3482d570e

Summary:
These are equivalents to Netty's channelActive and channelInactive, but we've been calling channels transports so I'm staying consistent.
I skipped integrating this into TAsyncTransportHandler because thrift still does manual CB attachment/detachment and it's unclear how that fits into this model
If my suspicions are correct, it *should* be possible to make attachReadCallback and detachReadCallback private in AsyncSocketHandler, right? And perhaps get rid of the event base modifier methods? What's our use case for those?

Test Plan: unit, employ in telnet server

Reviewed By: davejwatson@fb.com

Subscribers: fugalh, alandau, bmatheny, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2044520

Signature: t1:2044520:1431551998:af1de358b5dbefcca148814015d8e9f63f458d5d

Summary:
Decay so we don't try to instantiate this for attempts to copy Futures
See https://www.facebook.com/groups/499316706783616/permalink/863260220389261/

Test Plan: unit

Reviewed By: hans@fb.com

Subscribers: hannesr, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2062442

Signature: t1:2062442:1431551169:d1ba61537c998067ee7e6f4819f7e0817cc2e700

Summary: ASAN crashes on std::fill and doesn't respect no_sanitize_address attribute for some reason.

Test Plan: run fibers-test with ASAN

Reviewed By: stepan@fb.com

Subscribers: trunkagent, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2069437

Signature: t1:2069437:1431547972:7d2c7a6547f8d76b309a76ef69fd19a1de4ce261

Summary: This is more consistent with setWith, makeFutureWith, etc

Test Plan: unit

Reviewed By: hans@fb.com

Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2064667

Signature: t1:2064667:1431541614:a0e3f23d5effde13a93ce58ca3e21c7c3575215c

Summary:
I tried to fix this for default glibc but there are many mismatched-tags inside glibc itself. gcc-4.9-glibc-2.20 does not have such issue, using it.

```lang=bash
% fbconfig --clang --with-project-version clang:dev --extra-cxxflags=-Wmismatched-tags --extra-cxxflags=-ferror-limit=0 --platform-all=gcc-4.9-glibc-2.20-fb -r folly
% fbmake dev -j55 2> err
% perl -n -E 'm/\[-Werror,-Wmismatched-tags\]$/ && print' err | sort -u
./folly/experimental/fibers/TimeoutController.h:52:3: error: 'TimeoutHandle' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags]
folly/experimental/fibers/TimeoutController.h:52:3: error: 'TimeoutHandle' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags]
folly/experimental/JSONSchema.cpp:65:10: error: class 'ValidationContext' was previously declared as a struct [-Werror,-Wmismatched-tags]
./folly/futures/detail/Core.h:76:1: error: 'Core' defined as a class template here but previously declared as a struct template [-Werror,-Wmismatched-tags]
./folly/futures/Future.h:392:10: error: class 'Promise' was previously declared as a struct [-Werror,-Wmismatched-tags]
./folly/futures/Future.h:45:1: error: 'Future' defined as a class template here but previously declared as a struct template [-Werror,-Wmismatched-tags]
./folly/futures/Future-pre.h:137:1: error: struct 'Timekeeper' was previously declared as a class [-Werror,-Wmismatched-tags]
./folly/futures/Future-pre.h:23:18: error: struct template 'Promise' was previously declared as a class template [-Werror,-Wmismatched-tags]
./folly/futures/Future-pre.h:43:18: error: struct template 'Core' was previously declared as a class template [-Werror,-Wmismatched-tags]
./folly/futures/Promise.h:26:20: error: class template 'Future' was previously declared as a struct template [-Werror,-Wmismatched-tags]
./folly/futures/Timekeeper.h:23:18: error: struct template 'Future' was previously declared as a class template [-Werror,-Wmismatched-tags]
./folly/futures/Timekeeper.h:44:1: error: 'Timekeeper' defined as a class here but previously declared as a struct [-Werror,-Wmismatched-tags]
./folly/Singleton.h:378:10: error: class template 'SingletonHolder' was previously declared as a struct template [-Werror,-Wmismatched-tags]
./folly/wangle/ssl/SSLCacheOptions.h:17:1: error: 'SSLCacheOptions' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags]
./folly/wangle/ssl/SSLContextManager.h:29:1: error: class 'SSLCacheOptions' was previously declared as a struct [-Werror,-Wmismatched-tags]
./folly/wangle/ssl/SSLContextManager.h:32:1: error: class 'TLSTicketKeySeeds' was previously declared as a struct [-Werror,-Wmismatched-tags]
% perl -n -E 'm/\[-Werror,-Wmismatched-tags\]$/ && print' err | sort -u | wc -l
16
```

Updated manually. In all cases preferred tag from definition.

Test Plan:
Compile with clang dev and gcc-4.9-glibc-2.20-fb and see fewer errors:
```lang=bash
% fbconfig --clang --with-project-version clang:dev --extra-cxxflags=-Wmismatched-tags --platform-all=gcc-4.9-glibc-2.20-fb -r folly
% fbmake dev -j55
```

Reviewed By: markisaa@fb.com, meyering@fb.com

Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2066327

Signature: t1:2066327:1431471232:c65c2827398ba29a4022cc6a5647fac2b3aad717

Summary:
as above. I'm torn on whether to sugar "*this = SharedPromise<T>" as SharedPromise<T>::reset()
If I see another use case I'll probably do it

Test Plan: unit

Reviewed By: hans@fb.com

Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2064449

Signature: t1:2064449:1431476780:7113366b11feaf9e8a4ea1dc60fbafb36dd46ac5

Summary: I tried two "smart" ways (deriving from Promise, encapsulating a Promise) and got nothing but trouble. The KISS principle is applied with gusto in this diff.

Test Plan: unit, integrating in 3+ places in separate diffs

Reviewed By: hans@fb.com

Subscribers: craffert, trunkagent, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2035528

Signature: t1:2035528:1431393438:4e554cd30fa531d75b9267dccaade6dc516f2b15

Summary:
Make addFunctionInternal() publicly available, as an overloaded version of
addFunction().  This allows users to add functions with a specified poisson
distribution.

This allows us to deprecate our internal legacy version of FunctionScheduler,
and replace it with the folly version.

Test Plan: Confirmed all unit tests still pass.

Reviewed By: ldbrandy@fb.com

Subscribers: jwatzman, doug, net-systems@, exa, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2051699

Signature: t1:2051699:1431379841:f3547d1ed371503b0bf91b509a4ef03e881aa991

Summary:
when any system resource limit is reached, proxygen reduces the number of idle downstream sessions to accomodate new ones.

Test Plan:
canarying on edge241.01.ams3.  Here is the number of idle connection closed during pre load shedding stage.

https://www.facebook.com/pxlcld/ml7J

Reviewed By: afrind@fb.com

Subscribers: alandau, noamler, fugalh, bmatheny, folly-diffs@, jsedgwick, yfeldblum, chalfant, xning, alexkr

FB internal diff: D2030988

Tasks: 5698711

Signature: t1:2030988:1431369559:ce7328d51c7fd0afa7e9e5c19b0c66736d01fee1

Summary:
In most cases user is not aware of ASAN and fiber stack problem, thus if the stackSize is specified we're not detecting ASAN and probably will crash.
And thus it doesn't seem like a good idea to make it a user responsibility to detect ASAN.

Test Plan: tests

Reviewed By: andrii@fb.com

Subscribers: alikhtarov, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2058741

Tasks: 7016680

Signature: t1:2058741:1431131082:9a41eb40d756c9c7af0632f7ecd55c17d10bb189

Summary:
I figured it would make sense to implement all the collect* functions using a shared_ptr<Context>, instead of doing our manual reference counting and all that. Fulfilling the promise in the destructor seemed like the icing on the cake. Also saves some line of code.

Test Plan: Run all the tests.

Reviewed By: hans@fb.com

Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2015320

Signature: t1:2015320:1431106133:ac3001b3696fc75230afe70908ed349102b02a45

Summary: Since the old one is weak and slow.

Test Plan: Unit tests

Reviewed By: ott@fb.com

Subscribers: trunkagent, maxime, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2052630

Tasks: 6998080

Signature: t1:2052630:1431015271:bc90ccf99941902cd4bd43a0980238c616e66abf

Summary:
In order to create an EventBase'd Suprocess class, I'd like to be able to manage the lifetime of pipes independently of the lifetime of the process. To this effect, I factored out basic Pipe handling, and provided a function that detaches the pipe vector from the Subprocess object.

#6996492 a push-blocking test is broken in trunk

Test Plan: added a unit test, fbconfig -r folly && fbmake runtests && fbmake runtests_opt

Reviewed By: dancol@fb.com

Subscribers: yfeldblum, chalfant, dancol, wez, anarayanan, trunkagent, net-systems@, njormrod, folly-diffs@

FB internal diff: D1699969

Signature: t1:1699969:1430975299:30d291ab7fcc555edddf098b33095a5b29500e76

Summary: This almost always indicates a double-close bug, or a similarly nasty logic error. I don't dare make it a check, we may have some code running in production which would be broken by the CHECK, but this should give us early warning of any such bugs.

Test Plan:
```
fbconfig folly/test:file_test folly/test:file_util_test
fbmake runtests && fbmake runtests_opt
```

This test used to pass until @tudorb made me remove it due to worries about death tests messing with (currently absent) multi-threading:

```
+
+void testDoubleClose() {
+  File f("/dev/null");
+  checkUnixError(close(f.fd()));  // This feels so... wrong!
+  // The destructor will now try to double-close.
+}
+
+TEST(File, DCHECKDoubleClose) {
+#ifndef NDEBUG
+  // This test makes no sense otherwise, since this is a DCHECK.
+  EXPECT_DEATH(testDoubleClose(), "double-close-FD");
+#else
+  // That sound you hear is millions of lemmings falling to their doom.
+  testDoubleClose();
+#endif
+}
```

Reviewed By: tudorb@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2055610

Signature: t1:2055610:1431048270:a469d5c1f8182ffb74700908faa022e9613ed383

Summary:
Use std::chrono::steady_clock instead of clock_gettime(CLOCK_MONOTONIC).
In particular this fixes the build on Mac OS X, which doesn't have
CLOCK_MONOTONIC.

This also updates the code to use steady_clock::time_point correctly, instead
of using a raw milliseconds value for time since the epoch.

Test Plan:
Included unit tests, which were copied over from the legacy internal Facebook
(non-folly) version of this code.

Reviewed By: ldbrandy@fb.com

Subscribers: jwatzman, doug, fbcode-common-diffs@, net-systems@, exa, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2051557

Signature: t1:2051557:1431019654:ee76cfcf8318cc3d8a8d1522b3fc97f08831ecf4

Summary: Per discussion on D2040509 this is better.

Test Plan: Still builds.

Reviewed By: yfeldblum@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2051099

Signature: t1:2051099:1430949575:cc167b57f2d6ff42a73dee4e65d22d04932bb279

Blame Revision: rFBCODE9bdb427be1ef80b612e4f364db7809c6351cfe1c

Summary:
OS X doesn't support constructor init priorities, at all. AIUI,
it's a limitation of their actual binary format and loader, not just a
tooling/compiler limitation.

This particular usage appears to just be for for logging/bug-finding
purposes, so it looks like just removing the priority on OS X isn't the
end of the world?

Test Plan: g++-4.9 on OS X compiles this file now.

Reviewed By: njormrod@fb.com

Subscribers: ldbrandy, jdelong, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2040557

Signature: t1:2040557:1430975025:73f817b5d19a18dca6b19ba783dbea99192cbc41

Summary: Signed-off-by: Nicholas Ormrod <njormrod@fb.com>

Test Plan:
fbconfig -r folly && fbmake runtests

Reviewed By: yfeldblum@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2042952

Tasks: 6783581

Summary: Signed-off-by: Nicholas Ormrod <njormrod@fb.com>

Test Plan:
fbconfig -r folly && fbmake runtests

Reviewed By: yfeldblum@fb.com

Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2043151

Tasks: 6783581

Summary:
This is for OS X; there is apparently some difference between
its types and Linux's typical types, causing incomopatibilities between
a `long int` and a `long long int`. These two explicit template
instantiations fix the issue.

Test Plan: g++-4.9 on OS X compiles these files now.

Reviewed By: lucian@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2040509

Signature: t1:2040509:1430516624:9db8146b7824c0d09bac418a10a5f54451cdd5db

Summary:
I just had topaggr built from trunk crash with https://phabricator.fb.com/P19825084. It seems that
placing `FOLLY_DISABLE_ADDRESS_SANITIZER` next to the function definition has no effect. Though
what's strange, https://phabricator.fb.com/D2036280 test plan says the false-positive crashes
stopped after that diff. Have we run the tao script on the latest revisions of that diff? Anyway,
clang/gcc docs clearly say the attributes belong to declarations, not definitions, so let's do that.

Test Plan:
Compiled, unit tests.

Reviewed By: aap@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant, soren

FB internal diff: D2042149

Signature: t1:2042149:1430681824:aea21b9a1fcddfd5585180ba7f526c3a6ee0c8bf

Summary:
A client example to match telnet server.

Required a couple additions:
* future result when socket actually connects, similar to netty
* clients support IOThreadPoolExecutor groups
* a pipeline stage to make sure everything runs in the right eventbase thread.

Test Plan:
fbconfig follg/wangle/example/telnet && fbmake dbg
telnet_server
telnet_client

Reviewed By: hans@fb.com

Subscribers: doug, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant

FB internal diff: D2010289

Signature: t1:2010289:1430766232:65c6f946e454000f6ea9f41b49197ddbeea5ba3f