Utility that converts from prettyPrint format back to double (e.g. 10M = 10 000 000)

Summary: Utility is doing reverse of prettyPrint. This is a first sketch.

Test Plan:
1) We can reverse all tests from prettyPrint test and use for our function. For now I just reversed several of them
2) We can also test prettyPrint and prettyToDouble together by checking whether prettyToDouble(prettyPrint(X)) == X. This is implemented.

Reviewed By: marcelo.juchem@fb.com

FB internal diff: D1159879
Add loopOnce() method to folly::EventBase

Summary: Add loopOnce() method which provides functionality similar to event_base_loop(base, EVLOOP_ONCE);

Test Plan: fbmake

Reviewed By: simpkins@fb.com

FB internal diff: D1249753
Add ability to silence callbacks for Subprocess::communicate

Summary:
Subprocess::communicate callbacks are level-triggered, which makes writing
"chatty" communication protocols difficult -- you often want to silence the
write callback until you read the expected message. Add
Subprocess::enableNotifications() for this purpose.

Test Plan: test added

Reviewed By: lucian@fb.com

FB internal diff: D1251564

@override-unit-failures
Fix TIMED_SYNCHRONIZED_CONST bug

Summary:
TIMED_SYNCHRONIZED_CONST is acquiring a read-write lock but releasing a shared lock.  Chaos ensues.
@override-unit-failures

Test Plan: Add unit test, test times out before fix, passes after fix.

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1251518

Blame Revision: D327492
(wangle) Use an atomic_flag to make FutureObject threadsafe

Summary:
There are two operations on `FutureObject` (the backing object that both `Future` and `Promise` front), which are not threadsafe currently. Those are `setContinuation` and `fulfil`. They're not threadsafe because they have a race condition between checking to see whether they should run the continuation and the other side making its modification. This diff introduces a `std::atomic_flag` variable to avoid the race and make these threadsafe.

NB Making `Future`/`Promise` threadsafe does not make this pattern safe:

f1.via(...).then(...).then(...)

(In a hypothetical world where `Future::via` is another name for `executeWithSameThread`)
There is a race between the future from `via` and the call of `then` (and between the first and second `then`s), so the `then`s could execute in the far thread as intended, or they could execute in the current thread (probably not what was intended). This diff does not solve that semantic problem of which thread this runs in. But it does make it safer, in that all those continuations will always execute, just maybe not in the thread you had intended.

You may ask what is the benefit if that semantic problem still exists? That's up for debate. I think the safety is worth it: at least everything a n00b throws at it will *work*. The question of thread semantics can iterate. If we end up with thread semantics that really don't need locks (e.g. maybe because we move to an Rx/Later style "launch" at the end of a chain) we can always toss this atomic.

How does this affect performance? I'm doing some experiments and going to write up my findings. Early results indicate that outlier performance is impacted but not by a lot, but don't count those chickens until I hatch them. Part of the reason for sending this diff out is to run windtunnel experiments.

Test Plan: tests, benchmark, close inspection

Reviewed By: davejwatson@fb.com

FB internal diff: D1241822
A few missing includes

Summary: These were required to build folly on OSX.

Test Plan: build

Reviewed By: davejwatson@fb.com

FB internal diff: D1256856
Bugfix in iterator emplace

Summary:
Subtle bugfix to fbvector

Reproduction requirements:
- emplace into a vector at a non-end position
- the vector has enough capacity for the extra elements
- the value type's internal state is poisoned after a move

What should happen, explained by picture:

INITIAL SETUP

abc1234XY____
^
want to insert two elements here

FIRST STEP: uninitialized move-construction
x and y are initialized, but could be in an invalid state

abc1234xyXY__

SECOND STEP: move-assignment, in reverse order

abc123xy4XY__
abc12xy34XY__
abc1xy234XY__
abcxy1234XY__

What actually happens:
An indexing error causes the entire tail (##1234xy##) to be
move-assigned, instead of the intended head of the tail (##1234##).

If the data type's move operator does not invalidate its own data (i.e.
move is essentially a copy, as is the case with atomic types) then the
move assignment of ##y## onto ##Y## and ##x## onto ##X## is basically a
no-op. However, for types that do invalidate their own data when being
the source of a move (e.g. non-empty vectors and fbvectors), then the
end result will have bad data in place of ##X## and ##Y##.

Detection:
This bug has lain dormant for a while.

Very few people emplace into a vector, and those few who do could be
saved by using a copy-movable type like int.

The original test case did not use a data type which poisoned itself
after being the source of a move, so the tests did not notice any
oddities.

A new testsuite, which does poison itself, did notice.

Test Plan:
re-enable the test/stl_test mega-test. Run it. All tests
pass.

fbconfig -r folly && fbmake runtests_opt

Run fbvector through the new test suite (which initially caught the
error). It now passes.

Reviewed By: robbert@fb.com

FB internal diff: D1257258
Adding support for signed integers

Summary: For use with Thrift::Frozen, especially.

Test Plan: Unit tests

Reviewed By: philipp@fb.com

FB internal diff: D1255257
make ConcurrentSkipList ctor public

Summary:
There is no reason to force heap allocation for
`ConcurrentSkipList`.

Test Plan: fbconfig -r unicorn/test && fbmake opt -j32

@override-unit-failures

Reviewed By: lucian@fb.com

FB internal diff: D1261183
configurable node allocator for ConcurrentSkipList

Summary:
Allow specifying `SimpleAllocator` to use for node allocation.
Added optimizations for arena allocators.

Test Plan: fbconfig -r folly/test && fbmake opt -j32

Reviewed By: soren@fb.com

FB internal diff: D1261546
(Folly/FBString) Fix compilation time of test with opt

Summary: Now compiles in 18 seconds. Took two minutes before.

Test Plan: `fbmake runtests_opt`

Reviewed By: smith@fb.com

FB internal diff: D1243689
(wangle) codegen then() variant tests

Summary:
When all the variants I am dreaming of work, there's a little more than
100 tests generated.

Test Plan: fbmake runtests

Reviewed By: hannesr@fb.com

FB internal diff: D1258754
fix automake

Summary:
Automake complains there are two Malloc.cpp rules - rename one of them.

Facebook: Actually this file doesn't even build in fbconfig - is it still necessary?

Test Plan: autoreconf -i on ubuntu doens't fail

Reviewed By: pgriess@fb.com

FB internal diff: D1257372
Fix make check

Summary: Fix make check.  Benchmark.cpp was included twice, eventfd doesn't exist anymore.

Test Plan: autoreconf -i; ./configure; make check on ubuntu

Reviewed By: pgriess@fb.com

FB internal diff: D1259706
folly: accommodate fact that clang's strlen is not constexpr

Summary:
* folly/folly-config.h (FOLLY_HAVE_CONSTEXPR_STRLEN): Define to
zero when compiling with clang, since clang's strlen is not constexpr.

Test Plan:
Run this:
fbconfig --clang --with-project-version clang:dev folly/test && fbconfig dbg
and observe that the following no longer strikes:
folly/test/RangeTest.cpp:304:25: error: constexpr variable 'hello1' must be initialized by a constant expression

I also tried using clang-3.4 (the current default),
fbconfig --clang folly/test && fbmake dbg
with these results:
https://phabricator.fb.com/P8583443

Reviewed By: pgriess@fb.com

FB internal diff: D1262840
fix ConcurrentSkipList::Recycler layout

Summary:
D1261546 introduced regression in `sizeof(ConcurrentSkipList)`.
In case of `NodeAlloc = folly::SysAlloc`, size of an empty `NodeAlloc` struct
is 1 byte, due to the alignment requirements of the next field, it got
translated into wasting 8 bytes.

Test Plan: fbconfig -r folly/test && fbmake opt -j32

@override-unit-failures

Reviewed By: lucian@fb.com

FB internal diff: D1264730
Make header compatible with warp