Summary: Directly pass the arguments to respective constructors.
Instead of first making temporary and then pass that.

Closes #218

Reviewed By: @yfeldblum

Differential Revision: D2156978

Pulled By: @sgolemon

Summary: Fix leaks in unit tests

Reviewed By: @djwatson

Differential Revision: D2153681

Summary: It is often useful to retrieve the value preceding the current value
in an Elias-Fano iterator, for example when the list represents
adjacent ranges. This diff implements a new method `previousValue` in
`EliasFanoReader`.

It also adds a new `kUnchecked` boolean template argument to
`EliasFanoReader` which skips bounds checking.

Reviewed By: @philippv

Differential Revision: D2155049

Summary: add remove<T>, remove(Handler*), removeFront(), removeBack() to Pipeline
employ these to fix up reusing client pipelines with client dispatchers, which in turn fixes the broken ServiceTest

Reviewed By: @djwatson

Differential Revision: D2152636

Summary: AtomicUnorderedInsertMap is a concurrent hash table that firmly
at the performance end of the generality <-> performance spectrum.
If you don't need updates (or can use your own concurrency control when
overwriting values), you never need to delete, and you can predict your
capacity perfectly, then you will get wait-free reads, lock-free inserts,
safe concurrent iteration, and excellent cache and performance outlier
behavior.  Arbitrary key and value types are supported.

Reviewed By: @yfeldblum

Differential Revision: D2145281

Summary: the openssl improvement does not support compression and decompression.

Reviewed By: @Invalid auth token., @afrind

Differential Revision: D2151003

Summary: This reverts commit 0968dcc2f0e02998fa53007853e0c0aad0a423b7.

Reverts D2151582

Reviewed By: @​iainb

Differential Revision: D2153840

Summary: Since readCallback_ could be uninstalled in any of callbacks,
we need to ensure that readCallback_ != nullptr before calling
handleRead.

Reviewed By: @djwatson

Differential Revision: D2140054

Summary: Because Ex resolves to SomeException&, and then all the tests in optimize<>
fail.

Reviewed By: @yfeldblum

Differential Revision: D2152893

Remove duplicate header file
Somehow this was already correct in the internal repo, but not the external one.
Thanks!

Summary: Directly pass the arguments to respective constructors.
Instead of first making temporary and then pass that.

Closes #218

Reviewed By: @JoelMarcey

Differential Revision: D2151582

Pulled By: @sgolemon

Summary: Defaulted (*=default*ed) default constructors are better
because they can be constexpr and/or noexcept when C++ Standard
thinks it is right to do so. And they remain user-declared rather
than user-provided. Regarding *=default*ed default constructor,
benifit is that the work might be done during compilation and we
might not need to worry about exception paths. And for destructors,
apart from that that =defaulted definition is in sync with defaulted
default constructor we might discover that in some cases "() {}" might
be ill-formed when "= default;" compiltion indicates so. If =defaulted
definition for destructor doesn't do any harm then why not go for it.

Closes #216

Reviewed By: @yfeldblum

Differential Revision: D2145322

Pulled By: @sgolemon

Summary: We might be doing:
1) Create a temporary
2) Copy/Move out of it
3) Destroy that temporary.
Which isn't needed in many places.
And copy/move elision doesn't work for a temporary
bound to a reference.

We can forward arguments, directly.
To get the work done three constructors were added.

Closes #222

Reviewed By: @JoelMarcey, @yfeldblum

Differential Revision: D2151731

Pulled By: @sgolemon

Summary: To be able to use fiber lock in thrift

Reviewed By: @brianwatling, @yfeldblum

Differential Revision: D2149936

Summary: parseLeadingNumber does not contain EOS validation and raise an exception when '/sys/devices/system/cpu/cpu0/index0/shared_cpu_list' contains only one number like '0'.
Closes #207

Reviewed By: @yfeldblum

Differential Revision: D2148015

Pulled By: @sgolemon

Summary: Some internal malloc shims broke on using folly::ThreadLocal, so only do that for `__APPLE__`.

Reviewed By: @brianwatling

Differential Revision: D2151318

Summary: Clang warns when types with vtables are memcpy'd. If the type
has declared itself to be relocatable, then this is the desired
behavior. If the type has not declared itself to be relocatable, then
the memcpy codepath is dead. However, the dead codepath is still
instantiated (it's inside an if block with a static check, but c++
doesn't have static-if), so the compiler spits out a nasty warning
anyways.

Each memcpy reference inside of fbvector has been void-ified. I have
looked at all the codepaths leading to the memcpys, and see that they
have isRelocatable or isTriviallyCopyable checks.

Reviewed By: @markisaa

Differential Revision: D2148286

Summary: As in title

Reviewed By: @djwatson

Differential Revision: D2151092

Summary: For standard containers, assignment tries to reuse heap space.
Dynamic assignment does not - it calls destroy(), and then reconstructs
a new dynamic. In the case that the old and new types are the same (eg
assigning a dynamic-vector to a dynamic-vector) we can call through to
the underlying type's assignment operator.

Reviewed By: @jdelong

Differential Revision: D2148093

Summary: this taks advantage of the SSL_write_iovec function to improve CPU.  According our testing, it saves 10+% CPU.

Reviewed By: @djwatson

Differential Revision: D2119223

Summary: Folly still continue to build and work on earlier boost versions(boost < 1.56).

**boost::context::make_fcontext() change history:**
* __1.55:__    fcontext_t * make_fcontext( void * sp, std::size_t size, void(* fn)(intptr_t) );
* __1.56:__    fcontext_t make_fcontext(void* sp,std::size_t size,void(*fn)(intptr_t));

**boost doc:**
http://www.boost.org/doc/libs/1_55_0/libs/context/doc/html/context/context/boost_fcontext.html
http://www.boost.org/doc/libs/1_56_0/libs/context/doc/html/context/context/boost_fcontext.html
Closes #205
Closes #210

Reviewed By: @jwatzman

Differential Revision: D2148069

Pulled By: @sgolemon

Summary: Some OSs have python named according to a version ID
e.g. `python2.7` without a symlink from plain `python`

Use autotool's AM_PATH_PYTHON to search for a suitable interpreter
and use that to generate the *Tables.cpp files.

Closes #109

Reviewed By: @yfeldblum

Differential Revision: D2147977

Summary: On non-Linux systems, the autotools-based build system conditionally appends `detail/Clock.h` to `libfollybase_la_SOURCES` – even though that file is in there statically no matter what (as per [line 46](https://github.com/facebook/folly/blob/master/folly/Makefile.am#L46)), which causes the `install` command to error out trying to install the file twice, during `make install`… this patch takes out the conditional append.
Closes #201

Reviewed By: @yfeldblum

Differential Revision: D2148004

Pulled By: @sgolemon

Summary: OSX doesn't support C++11's `thread_local`. :-/ (yet? http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports/29929949#29929949)
We have `FOLLY_TLS` in `Portability.h` https://github.com/facebook/folly/blob/master/folly/Portability.h#L163-L175

So replace the usages of `thread_local` with `FOLLY_TLS`. But `__thread` is not drop-in compatible with `thread_local`, specifically the former requires global storage and needs a constexpr initializer, and a trivial destructor.

`futures/QueuedImmediateExecutor` now uses `folly::ThreadLocal` (because `std::queue` has a non-trivial destructor). It might end up in one more alloc, per thread. I also rearranged the code to clarify the fact that although there may be many `QueuedImmediateExecutor`s, they all share the same queue per thread.

I didn't use `folly::ThreadLocal` for fibers, because I thought it might be too expensive. But now I'm not so sure. I had to do the "check for default and then initialize" thing because of the requirement for constexpr initialization for `__thread` (and therefore `FOLLY_TLS`).

Reviewed By: @jsedgwick

Differential Revision: D2140369

Summary: Something's broken here, will track fixing in #7372389

Reviewed By: @jsedgwick

Differential Revision: D2144077

Summary: They don't pass, but they build!

Reviewed By: @jsedgwick

Differential Revision: D2141717

Summary: Discard a result but propagate an exception. cf https://www.facebook.com/groups/715931878455430/permalink/879624552086161/

Reviewed By: @​sammerat

Differential Revision: D2144567

Summary: This fucntion will be re-used for different SSL write functions in future.

Reviewed By: @djwatson

Differential Revision: D2117529

Summary: OSX apparently knows better than all of us plebes, and got rid of anonymous semaphores. Rather than try to work around that directly, I just switched to folly::LifoSem, which seems like a not-terrible idea anyway.

Reviewed By: @jsedgwick

Differential Revision: D2143566

Summary: ((not yet) more performant) sugar for `via(&x).then(func)`

Reviewed By: @​hannesr

Differential Revision: D2131246

Summary: Give IOBuf a copy constructor, which clones the whole chain. (IOBufs have
shared pointer semantics). You could argue for cloning one single IOBuf,
but cloning the whole chain has the nice side effect of making Thrift
structures with IOBufs in them copyable, so there's that.

Reviewed By: @djwatson

Differential Revision: D2127209

Summary: Next step towards killing RequestEventBase hackery.
Use EBs from global IO executor instead

Reviewed By: @fugalh

Differential Revision: D2123142

Summary: this is going to be a really common pattern, so I'm providing a shortcut

Reviewed By: @fugalh

Differential Revision: D2146008

Summary: No reason to go through the whole Promise rigamarole. Add an appropriate Core ctor and use that to make a completed Future with just the core alloc

Note the big win in the `constantFuture` benchmark.

```
Before:
============================================================================
folly/futures/test/Benchmark.cpp                relative  time/iter  iters/s
============================================================================
constantFuture                                             120.50ns    8.30M
promiseAndFuture                                  91.99%   130.98ns    7.63M
withThen                                          28.17%   427.77ns    2.34M
----------------------------------------------------------------------------
oneThen                                                    430.48ns    2.32M
twoThens                                          58.03%   741.86ns    1.35M
fourThens                                         31.85%     1.35us  739.97K
hundredThens                                       1.61%    26.80us   37.32K
----------------------------------------------------------------------------
no_contention                                                4.58ms   218.48
contention                                        83.70%     5.47ms   182.86
----------------------------------------------------------------------------
throwAndCatch                                                8.09us  123.55K
throwAndCatchWrapped                              94.43%     8.57us  116.67K
throwWrappedAndCatch                             154.69%     5.23us  191.12K
throwWrappedAndCatchWrapped                      614.06%     1.32us  758.70K
----------------------------------------------------------------------------
throwAndCatchContended                                     967.54ms     1.03
throwAndCatchWrappedContended                    103.48%   935.04ms     1.07
throwWrappedAndCatchContended                    148.24%   652.70ms     1.53
throwWrappedAndCatchWrappedContended            14313.28%     6.76ms   147.94
============================================================================

After:
============================================================================
folly/futures/test/Benchmark.cpp                relative  time/iter  iters/s
============================================================================
constantFuture                                              69.11ns   14.47M
promiseAndFuture                                  55.12%   125.37ns    7.98M
withThen                                          16.49%   419.18ns    2.39M
----------------------------------------------------------------------------
oneThen                                                    370.39ns    2.70M
twoThens                                          55.11%   672.05ns    1.49M
fourThens                                         29.00%     1.28us  782.89K
hundredThens                                       1.23%    30.22us   33.09K
----------------------------------------------------------------------------
no_contention                                                4.56ms   219.46
contention                                        82.82%     5.50ms   181.77
----------------------------------------------------------------------------
throwAndCatch                                                8.30us  120.42K
throwAndCatchWrapped                              96.40%     8.61us  116.08K
throwWrappedAndCatch                             162.66%     5.11us  195.89K
throwWrappedAndCatchWrapped                      680.39%     1.22us  819.36K
----------------------------------------------------------------------------
throwAndCatchContended                                     979.17ms     1.02
throwAndCatchWrappedContended                    103.09%   949.84ms     1.05
throwWrappedAndCatchContended                    153.55%   637.71ms     1.57
throwWrappedAndCatchWrappedContended            10468.47%     9.35ms   106.91
============================================================================
```

Reviewed By: @fugalh, @​hannesr

Differential Revision: D2144664

Summary: Use of std::max from libc++ resulted in error.
std::max found type of its arguments diffrent
whereas it expected them to be same.
This diff fix the error.
Closes #223

Reviewed By: @yfeldblum

Differential Revision: D2144639

Pulled By: @sgolemon

Summary: Closes #211

Reviewed By: @Gownta, @lbrandy

Differential Revision: D2144702

Pulled By: @sgolemon

Summary: Closes #202

Reviewed By: @paulbiss

Differential Revision: D2144850

Pulled By: @sgolemon

Summary: Minor typo when referencing `std::allocator`
Closes #84

Reviewed By: @yfeldblum

Differential Revision: D2144830

Pulled By: @sgolemon