Summary:
I'm not sure about the name Lift now. We are lifting, yes, but are we lifting into Unit, or into "can't be void because void is unit"? But LiftIntoNonVoid is a bit verbose. I'm totally open to other names or arrangements. We could also rename `is_void_or_unit`, but to what?

I reimplemented `is_void_or_unit` in terms of `Unit::Lift` because it's kinda cool but also to provide a little motivational example to the reader for why Lift exists in the first place.

Test Plan: Still builds and passes tests. Nothing significant depends on this yet.

Reviewed By: hannesr@fb.com

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

FB internal diff: D2102147

Tasks: 6847876

Signature: t1:2102147:1432742966:a03973a45882d3e9f6fa7158ef393b148cbe16fc

Summary:
Add the option to instrument every EventHandler that runs in a
EventBase.

Test Plan:
Unit tests

Reviewed By: davejwatson@fb.com

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

FB internal diff: D2044546

Tasks: 6958000

Signature: t1:2044546:1432221358:6500d6c1a6631d7a06a18e874d051f2ff3108e10

Summary: See task

Test Plan: runtests

Reviewed By: jsedgwick@fb.com

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

FB internal diff: D2101549

Tasks: 7225286

Signature: t1:2101549:1432688294:5fb9d7370c38c1392429a09ba48b131cac16647d

Summary: copy everything but example/

Test Plan: fbconfig -r folly/wangle && fbmake runtests

Reviewed By: hans@fb.com

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

FB internal diff: D2100811

Tasks: 5802833

Signature: t1:2100811:1432678173:6c336fe53aa223993f6f82de4ac91b3c19beacf1

Summary: this preserves history and will be followed by a copy diff

Test Plan: next diff will compile

Reviewed By: hans@fb.com

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

FB internal diff: D2100784

Tasks: 5802833

Signature: t1:2100784:1432677219:838a336d84918145d19c6cfa4290dd58374821fd

Summary: broken by D2096146

Test Plan: arc unit

Reviewed By: andrewcox@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2100773

Signature: t1:2100773:1432676073:a72e72fa5fb915b027fdfd31dd814d02e6606858

Test Plan: built folly

Reviewed By: mshneer@fb.com

Subscribers: davejwatson, mshneer, trunkagent, alandau, bmatheny, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2096146

Tasks: 6337419

Signature: t1:2096146:1432658670:4ff00e4274412519dc3b02d2a849b7ff289ac979

Summary: see task

Test Plan: OK

Reviewed By: hans@fb.com

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

FB internal diff: D2099416

Tasks: 7166291

Signature: t1:2099416:1432658571:4ae632c218c4764f23e4b189167f6fdaff13dc2d

Summary:
1. Eliminate some string -> StringPiece -> strings conversions
2. Mcrouter: eliminated unnecessary inlining by moving slow path logic into its own method.

Using a test setup with shadow sampling enabled and shadowing some requests,
(typical prod setup), this brings down the cost from ~1.4% cpu in standalone mcrouter to ~0.2%:

```
before:

+ 0.70%          3898  mcrouter_orig  mcrouter_orig  [.] FbAdditionalProxyRequestLogger::logReply
+ 0.13%           864  mcrouter_orig  mcrouter_orig  [.] EventGroup<ScubaRow>::processExtraSamplers
+ 0.58%          3347  mcrouter_orig  mcrouter_orig  [.] DynamicScubaSampler::getSampler

~ 1.41% total

after:

+ 0.18%          1223  mcrouter_fix  mcrouter_fix  [.] FbAdditionalProxyRequestLogger::logReply
+ 0.04%           205  mcrouter_fix  mcrouter_fix  [.] EventGroup<ScubaRow>::processSampler

~ 0.22% total
```

Fiber local optimization might have more of an effect.

Test Plan:
unit tests

Reviewed By: pavlo@fb.com

Subscribers: trunkagent, fbcode-common-diffs@, alikhtarov, folly-diffs@, yfeldblum, darshan, chalfant

FB internal diff: D2089133

Tasks: 5414865

Signature: t1:2089133:1432338487:4158dc6b720c04f43820193e73b98d4197afcffa

Summary: Need to cut this dep on wangle out of folly as we're moving wangle to its own repo

Test Plan: chimera unit

Reviewed By: rushix@fb.com

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

FB internal diff: D2092122

Signature: t1:2092122:1432239179:9261c1b3a3a346b886b15899d25a4d0530d4e890

Summary:
Reverting diff to fix the build.

Test Plan: contbuild rule that failed to build is okay now

Reviewed By: ldbrandy@fb.com

Summary:
strncpy is bad.  strlcpy is somewhat less bad.  We already had
this function, but let's move it somewhere more reasonable.

Test Plan: runtests

Reviewed By: ldbrandy@fb.com

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

FB internal diff: D2062632

Signature: t1:2062632:1431969926:cc7f7283073d0242fe8f361efac2557aa0b0a481

Test Plan: search, and fbmake

Reviewed By: delyank@fb.com

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

FB internal diff: D2093523

Signature: t1:2093523:1432249208:84a27e2328636c2aafe43412f61a693b5645b895

Summary: Without <atomic>, this fails to compile with clang:dev and newer glibc.

Test Plan:
fbconfig --clang --with-project-version=clang:dev --with-project-version=llvm_compiler_rt:dev --platform-all=gcc-4.9-glibc-2.20 --sanitize=address mcrouter/lib/network:client-test-sync && fbmake dbg

Reviewed By: pavlo@fb.com

Subscribers: folly-diffs@, yfeldblum, chalfant

FB internal diff: D2093709

Signature: t1:2093709:1432250378:2b78c142598bf0a7b0869089c752f5ccdae9da22

Summary:
This includes a change to Range to move operator<< into the
header, to achieve the goal.  Specifically, see format_test,
dynamic_test, json_test, demangle_test

Test Plan: fbconfig -r buck && fbmake runtests

Reviewed By: njormrod@fb.com

Subscribers: darshan, tjackson, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2063698

Signature: t1:2063698:1431467309:069da6d74bb5c384e7a21e6be19a4b20466bdd92

Summary:
I'm looking into pulling parts of folly (right now, dynamic,
json, and their dependencies) into fbandroid for use as part of xplat.
This diff includes a few kinds of changes: portability fixes for arm;
reduce the size of the code generated by moving non-templated
functions and methods into cpp files; refactoring header usages which
require extra compiler flags on android to cpp files; and slicing up
the libraries a bit differently to reduce dependencies.  This should
all be backward-compatible, and do no harm to fbcode.

Test Plan: runtests, sandcastle

Reviewed By: njormrod@fb.com

Subscribers: darshan, davejwatson, tudorb, dancol, folly-diffs@, yfeldblum, chalfant

FB internal diff: D2057797

Tasks: 7005344

Signature: t1:2057797:1432145435:fa10f129fc669e682da5b4b207fc96986ca035fc

Summary:
Based on a more thourough reading of finagle's interface:
* adds close/isAvailable, which seem very close to thrift's interfaces
* ComposedServices are hardcoded to underlying services, to simplify the code (means extra allocs?)
* Made everything a shared_ptr
* Addd ServiceFactoryFilters

Test Plan: Updated the existing unittests and added some new ones

Reviewed By: jsedgwick@fb.com

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

FB internal diff: D2037206

Signature: t1:2037206:1432147489:3464d4c12a9e434d4973febcabbf7b2b3a883257

Summary:
tupleRange<start, n>(tuple): return a tuple consisting of a range of elements
from the given tuple

tuplePrepend(x, tuple): return a tuple consisting of prepending x to the given
tuple.

For Lispies:

std::get<0>(tuple) is car.
tupleRange<1>(tuple) is cdr.
tuplePrepend(x, tuple) is cons.

Test Plan: test added

Reviewed By: lesha@fb.com

Subscribers: trunkagent, lesha, ilyam, folly-diffs@, yfeldblum, chalfant, jhj, alerer, kma, pamelavagata, tulloch

FB internal diff: D2087568

Signature: t1:2087568:1432164681:18795d0e8bb01f38ffc6949ac233f514ab098355

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