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
cmake deps for finding libraries

current smake deps are boost (included), double-conversion, gflags,
glob, and pthreads
initial cmake file

deps are done and work well - moving stuff from config.ac into
cmake file for platform checks, then need to move testing stuff into
cmake - might move the testing stuff to subfiles
cmake build system working

Although the build system is not entirely complete (file generation and
test building and running is not finished yet, nor is more than a stock
folly build) this should be "good enough" to get a working makefile and
config for folly
Additional cmake features

Added noexcept to c++11 checks

added additional deps needed for IO portions of library (that apparently
don't build with the automake system)

organized libraries to be built and listed source files for each
properly
generation of files can now be forces

Commit generated files, these don't change much and not every windows
box wants to install python to create these
Additional adjustments to cmake

Prefix some items with FOLLY_ and add some c++11 workaround capabilities
some prefixed include define blocks

for byteswap and c++config.h
noexcept def support

also make sure crazy windows.h does not overwrite min/max with a macro
Rearranging and adding win32 include dir

include win32 dir for includes which will have windows specific
posix wrappers, and move compiler options flag to compiler.cmake
fix win32 include path
Fix constexpr definition

also add generated fingerprinttables file
fix noexcept macro
add alignof and alignas to c++11 detection
Add libevent to deps