Address clang sign warning in Format-inl.h

Summary:
This has been bothering me for a while when I've been trying to
verify builds with clang. This generates a ton of spew and the current
code can't actually handle non-default negatives so let's just throw if
we see one.

Test Plan: fbmake runtests

Reviewed By: meyering@fb.com

Subscribers: mathieubaudet, njormrod, folly-diffs@, bmatheny, benyluo, shikong, kmdent, fma, ranjeeth, subodh

FB internal diff: D1643881

Signature: t1:1643881:1414523777:085035ce8c280fbd6481b2ce0354b53b96fdc50e

kill threadgate

Test Plan: This diff is actually the test plan. It was contbuild bait. I fixed things that broke (in separate diffs), and then I rebased this on top, everything is green, and we pulled the trigger.

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1632937

Tasks: 5409538

Signature: t1:1632937:1414531009:4dbaa9513fbfba45a9c63e7be3de3646a6e926a2

Add MemoryIdler suppot to IOThreadPoolExecutor

Summary:
Idle memory in IO threads.   If loop is unused for a period of time, free associated memory, and call epoll again.

Had to add a new list of callbacks that don't make the loop nonblocking (i.e. using runInLoop() instead would use the nonblocking version of epoll).

Could bake this in to EventBase directly, but that seems like the wrong abstraction, since EventBase doesn't actually control the thread - for example, that approach would also free up memory for stack-allocated EventBases where they are used synchronously by clients.

This diff doesn't change IO scheduling at all - current IO work is round robin, so this probably only helps if the whole server is idle (at least until we add smarter scheduling)

Test Plan:
Based on top of D1585087.

fbconfig thrift/perf/cpp; fbmake dbg
_bin/thrift/perf/cpp/ThriftServer
_bin/thrift/perf/cpp/loadgen -num_threads=100 -weight_sendrecv=1 -cpp2 -async

Ran loadgen for a while, watched res memory in top.  Stopped loadgen.  After ~5 sec, res memory was much reduced.

Reviewed By: jsedgwick@fb.com

Subscribers: trunkagent, doug, fugalh, njormrod, folly-diffs@

FB internal diff: D1641057

Tasks: 5002425

Revert "D1587625 [thrift->folly] AsyncSocket"

Summary:

Test Plan:

Reviewed By: cgheorghe@fb.com

Subscribers:

FB internal diff: D1642334

Blame Revision: D1587625

improve io::Appender functionality

Summary:
Add an operator()(StringPiece) method to Appender, so it can be used
directly with folly::Formatter objects.  Also add printf() and vprintf()
methods to Appender, for places that need to use existing printf-style
formatting.

This also includes versions of push() and pushAtMost() that accept
ByteRange objects.  Previously we only had push() implementations that
took separate buffer and size arguments.

Test Plan: Added new unit tests to IOBufCursorTest.cpp

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, doug, net-systems@, exa, njormrod

FB internal diff: D1583684

Add missing headers

Summary: Jenkins ci build was broken for a while, so we missed these  in contbuild results

Test Plan: watch ci build for fbthrift

Reviewed By: hans@fb.com

Subscribers: doug, fugalh, njormrod, folly-diffs@

FB internal diff: D1641515

AsyncSocket

Summary:
Move async socket to folly.

Changes:
* Made an AsyncSocketException type instead of TTransportException: Some of the exceptions didn't fit nicely in to std::exception types (like TIMED_OUT).  There are some wrappers in thrift/lib/cpp/async to convert back to TTransportException, so all existing code still compiles.
* Moved read/write callbacks out of AsyncTransport: filters are going to want to do the read/write stuff separately (see revproxy/tunnel/filters, and discussions in D1483148).

Test Plan:
fbconfig -r thrift; fbmake runtests
contbuild should catch everything else - exception types shouldn't change for existing code

Reviewed By: dcsommer@fb.com

Subscribers: mshneer, folly-diffs@, trunkagent, doug, alandau, bmatheny, njormrod, fugalh, jsedgwick

FB internal diff: D1587625

(wangle) fix race in Core::detachOne()

Summary:
In D1618240 I introduced a race condition in `detachOne()`, where `detached_` is incremented and then tested. If the promise and future are racing, they can both see `detached_ == 2` in the conditional, and then they'll both try to free the Core object. This fixes that.

It also fixes a related problem (which actually showed up more often with the test I wrote), where we transition into the Done state before setting the value, and then `maybeCallback()` observes the state is Done (because we're just reading an atomic, not grabbing the lock, which is intentional), tries to execute the callback, but `folly::Optional` throws an exception because the value hasn't been set yet (at least in debug it does). I should have listened to my gut and kept the state assignment after the transition action in the first place.

Test Plan: New unit test

Reviewed By: jsedgwick@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@, mnd

FB internal diff: D1636490

Tasks: 5438209

Blame Revision: D1618240

unrevert "(wangle) express current Core functionality with a state machine""

Summary: Reverts D1633874. Companion to D1636490 which fixes the bug.

Test Plan:
git reverting code that was git reverted and hasn't changed in the interim
Won't be checked in without the companion bugfix diff (D1636490)

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1636487

Tasks: 5438209

Blame Revision: D1633874

Remove some leftover apache paths

Summary: EventBaseManager was moved to folly, we shouldn't have deps on apache

Test Plan: fbconfig -r folly/experimental/wangle/concurrency; fbmake runtests

Reviewed By: hans@fb.com

Subscribers: doug, fugalh, njormrod, folly-diffs@

FB internal diff: D1636006

Revert "(wangle) express current Core functionality with a state machine"

Summary:

Test Plan:

Reviewed By: harishs@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1633874

Tasks: 5438209

fix Future<const T>::value()

Summary: I'm still a little mystified how one makes a Future<const T> (I tried to make one explicitly in a test and failed), but this is clearly the bug @reedriley sees in https://phabricator.fb.com/D1620805#21

Test Plan:
fbconfig titan/cachius/test
fbmake

Reviewed By: reedriley@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, reedriley, folly-diffs@

FB internal diff: D1630378

Blame Revision: D1620805

move asyncserversocket to folly

Summary:
Changes:
* namespace to folly
* some std::chrono replacesments
* Moves shutdownSocketSet stuff to thriftserver instead of in the socket itself.
* Changes exception types.  I don't see anywhere that uses the TAsync*SERVER*socket exceptions depending on the TTransport type, but I could be wrong? I don't really know what to do about the exception types

unittests still postponed overnight.

Test Plan:
fbconfig -r thrift; fbmake runtests
fbconfig -r proxygen; fbmake runtests

Reviewed By: dcsommer@fb.com

Subscribers: hphp-diffs@, ps, folly-diffs@, anca, trunkagent, jsedgwick, fugalh, doug, alandau, bmatheny, njormrod

FB internal diff: D1579187

add PortableSpinLock.h to Makefile, unbreak fbthrift build

Summary:
fix fbthrift build, broken in D1621717

I wonder if it'd be possible to lint against this somehow. The jenkins failures are easy to miss especially on folly diffs with lots of failure noise (in this case it was still postponed)

Test Plan: wait for jenkins

Reviewed By: davejwatson@fb.com

Subscribers: njormrod, folly-diffs@

FB internal diff: D1630833

Schedule destroyInstances in registrationComplete

Summary: This makes it more likely that SingletonVaultDestructor won't be created after atexit calls.

Test Plan: unit test

Reviewed By: chip@fb.com

Subscribers: hphp-diffs@, ps, njormrod, folly-diffs@

FB internal diff: D1629804

Tasks: 5353022

(wangle) fix after-delete assert

Summary:
This would cause debug builds to do a bad thing (access the variable `this->detached_` within an assert, after `delete this`).

Test Plan: unit tests

Hopefully now that we have a dummy cpp file in `folly/wangle/detail` contbuild
will pick it up and all the dependencies will also run their tests.
Right now, we suspect maybe maelstrom (@wez) and adinvoicer and zookeeper
(@jying) and probably others are seeing this in unit test failures (esp. if
they use asan, which is rightly detecting read after free). Hoping contbuild
will catch them.

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@, wez, dcapel, jying, cgheorghe

FB internal diff: D1630301

Tasks: 5424546, 5435720

Blame Revision: D1618240

waitFor race workaround

Summary: Fixing the race will take some more thought. Probably a condvar. For now, I'm turning waitFor into a spinlock instead.

Test Plan: new unit test that deadlocks before the workaround

Reviewed By: jsedgwick@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1628015

Tasks: 5427828

(wangle) Fix a couple compilation issues

Summary: If you try to include files in a weird (but not incorrect) order you get compilation errors. No longer!

Test Plan: new dummy `cpp_binary` target

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, folly-diffs@, net-systems@, fugalh, exa, njormrod

FB internal diff: D1621083

(wangle) Interrupts (and therefore, cancellation)

Summary:
Modeled very closely after Finagle's interrupts. Compare with https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Promise.scala if you like.
The basic idea is the promise holder can register an interrupt handler, and then interrupts will call that handler. A typical handler would fulfil the promise with an exception (or special value) indicating that it was interrupted (if it was interrupted in time).
Raising an interrupt does not prevent setting a value or callbacks executing or any of that - it is only advisory to the promise holder.

Test Plan: I wrote some unit tests.

Reviewed By: davejwatson@fb.com

Subscribers: folly-diffs@, net-systems@, fugalh, exa, hannesr, njormrod

FB internal diff: D1620805

Tasks: 4618297

(wangle) express current Core functionality with a state machine

Summary:
This is a refactor of the current functionality to use a state machine (inheriting from `FSM`). This will make it easier to extend to do cancellation and Future collapsing. Performance is the same, maybe slightly faster (abt 1%). (I might be a little conservative with the atomics, it might be worth going through and reasoning about whether they all need to be atomic).

The state machine is two states, Waiting (no value), and Done (has a value). Transitioning to Done will execute the callback if it exists and we are active. Otherwise the callback will happen when it is set and active is true.

There is a subjective balancing act in place here, between making a state for every single mutable bit of information (which results in an explosion of states: hasValue X hasCallback X isActive X isCancelled …), and finding a sweet spot of expressivity. This isn't too far from the way Twitter did it, though we don't (yet) have all the states they have (and they don't have the concept of hot/cold futures). But I got there by way of replacing the `mutex_` with the state, after changing all those variables to atomics so they didn't need mutex protection (resulting in only `callback_` and `result_` needing it). I expect the state machine will morph as the rest of the functionality is added, but hopefully it will be easier to understand and keep correct (that's the idea anyway).

Test Plan: Tests still pass (and not by accident, I made several awesome mistakes along the way).

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod

FB internal diff: D1618240

Tasks: 4618297

(wangle) Core cleanup

Summary:
Just some cleaning hose in `detail::Core`.
- rename `fulfil` to `setResult`
- and `value_` to `result_`
- remove unnecessary helper methods (I can be convinced to keep them if you like them)

Test Plan: mechanical changes, tests still pass

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, folly-diffs@, net-systems@, fugalh, exa, njormrod

FB internal diff: D1618161

(wangle) deprecate Later and ThreadGate

Summary:
Later is now superfluous. Just hold a deactivated future (e.g. one returned by `Future::via`), and then activate (or destruct) it when you're ready.
ThreadGate has proven to be too rigid and too heavyweight to be really useful. And is superfluous now with `Future::via`. e.g.
f.via(east).then(a1).then(a2).via(west).then(b1).then(b2);

This is stage one of removing these: mark them deprecated.
Stage two will be for me to change all existing usages in our code to not use them.
Stage three will be to rip these out altogether.

Test Plan:
Everything still builds and works, but now with deprecation warnings.

fbconfig -r \
common/smc/cpp/tests \
folly/wangle \
langtech/audiens \
messaging/avscan \
messaging/maelstrom \
neteng/traffic_manager \
notifications/nudge/service \
tao/client \
zeus/datashuttle
fbmake runtests

Reviewed By: jsedgwick@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1626412

Tasks: 5409538

remove fireAndForget

Summary: It was deprecated, now is unused.

Test Plan:
fbgs
check contbuild

Reviewed By: hannesr@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1624221

(wangle) dummy cpp files

Summary: for great contbuild

Test Plan: these projects still build. contbuild should start picking them up, based on discussion with @robbert

Reviewed By: robbert@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, mwa, jgehring, fuegen, njormrod, folly-diffs@, robbert

FB internal diff: D1624206

Tasks: 5399744

(FSM) updateState with unprotected action

Summary:
Like the magic macros. As it says in the comment, this can lead to nicer code.
Also added/moved a couple examples to the top of `test/FSM.cpp`.

Test Plan: new tests

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod

FB internal diff: D1618184

sync wangle to makefile

Summary: as above

Test Plan:

Reviewed By: davejwatson@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1589439

Support NotificationQueue on iOS/Android

Summary:
This is the last of the changes to make folly and thrift portable. The old
thrift SpinLock implementation is exactly we
want here so port this into folly. If someone later makes efficeint
versions of MicroSpinLock for platforms other than x64 they can easily
be plugged in without changing the calling code.

Test Plan: compiled on multiple platforms

Reviewed By: alandau@fb.com

Subscribers: folly-diffs@, ldbrandy, trunkagent, alandau, bmatheny, njormrod, mshneer, shikong, benyluo, kmdent, fma, ranjeeth, subodh

FB internal diff: D1621717

Tasks: 5183325

Bump version to 13:0

Fix mcrouter opensource build

Summary: mcrouter now uses folly::Singleton.

Test Plan: visual

Reviewed By: andrii@fb.com

Subscribers: njormrod

FB internal diff: D1622647

Fix typo in folly::Optional

Test Plan: yes

Reviewed By: delong.j@fb.com

Fix one missing conditional for Android

Summary:
pthread_atfork isn't defined in the Android NDK (and therefore is not actually supported even though it's in bionic/libc) so don't call it there.

Test Plan: compiled on Linux, Android

Reviewed By: meyering@fb.com

Subscribers: njormrod, shikong, kmdent, fma

FB internal diff: D1620584

Tasks: 5183325

Fixing broken bits test

Summary: Buffer size calculation had fallen out of sync with the actual test code. Good thing we have ASAN!

Test Plan: Run the test with address santizer.

Reviewed By: mpawlowski@fb.com

Subscribers: mpawlowski, trunkagent, njormrod

FB internal diff: D1619472

Tasks: 5325399

Allow Optional<T> {=,!}= T comparisons in folly::Optional

Summary:
I can see how {<,>}{,=} comparisons might be ambiguous, but equality
should never be, so let's allow it.

Test Plan: tests

Reviewed By: tjackson@fb.com

Subscribers: trunkagent, njormrod

FB internal diff: D1618088

move shutdown socket set

Summary:
Move shutdownsocketset to folly, since it is a dep of the asyncsockets

Previoulsy tried moving it in to the server directly: D1583629, but had issues - close(fd) is called before the error callback, so we can't remove the fd before the close, which is essential to it working properly.

Just move it to folly instead.

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

Reviewed By: dcsommer@fb.com

Subscribers: mshneer, trunkagent, fugalh, jsedgwick, doug, alandau, bmatheny, njormrod

FB internal diff: D1594950

Conditionals for iOS / Android compilation

Summary:
Conditional changes required to compile on iOS and Android.

Test Plan: compiled on all platforms

Reviewed By: meyering@fb.com

Subscribers: kmccray, trunkagent, shilin, njormrod, ranjeeth, subodh, bmatheny

FB internal diff: D1618028

Tasks: 5183325

Don't throw in Singleton::get() if singleton is alive

Summary:
This is a fix for situations where you know that something is keeping singleton alive (by getting a weak_ptr and locking it), and request a singleton instance via get() method (if e.g. it's hard to pass a pointer to singleton instance from a method which locked it). If shutdown was scheduled - an exception was previously thrown even though the object was not destroyed yet.

This simplifies conversion of legacy code to folly::Singleton.

Test Plan:
fbconfig -r gatehouse/usersets/tests
fbmake runtests

Reviewed By: chip@fb.com

Subscribers: trunkagent, njormrod

FB internal diff: D1619311

Remove global init of ThreadLocal in Random

Summary:
Remove global initialization of ThreadLocal in Random
See https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Thread-Local.html

Static initializers and thread locals don't mix well, and we're seeing
some crashes which we think might be related to this.

Test Plan: Unit tests

Reviewed By: seanc@fb.com

Subscribers: trunkagent, seanc, njormrod

FB internal diff: D1617455

support for move-only types

Summary: universal references and perfect forwarding to the rescue

Test Plan: added demonstrative unit tests

Reviewed By: hans@fb.com

Subscribers: trunkagent, fugalh, njormrod, bmatheny

FB internal diff: D1592032

Tasks: 5283342

merge wangle/Executor.h and experimental/wangle/concurrent/Executor.h

Summary:
the one in concurrent/ is a bit more generic, so I kept that as Executor and renamed the existing one ScheduledExecutor

because Hans is surfing I took the liberty of renaming Action->Func as an alias for std::function<void()>, because I think it's more reflective
also kept the version of add() that doesn't force rvalue-reference as it's more user friendly and probably not less performant in common cases (insert reference to "want speed? pass by value" here)

Test Plan: compiled some major relevant bits, will let contbuild show me anything I missed

Reviewed By: hans@fb.com

Subscribers: trunkagent, rushix, fbcode-common-diffs@, fugalh, msk, njormrod

FB internal diff: D1591237

Tasks: 5279196

Schedule destroyInstances only when first singleton is created

Summary:
Right now destroyInstances is scheduled when SingletonVault is requested. This may change singleton destruction order (folly::Singleton-managed vs unmanaged singletons) when new singleton is registered with folly::Singleton (no matter if it is even used).
This diff changes it to be more stable.

Test Plan: servicerouter unittests

Reviewed By: chip@fb.com

Subscribers: njormrod, mshneer

FB internal diff: D1615213

Tasks: 5353022

Fix clang test compilation failures

Summary:
While working on other code I noticed folly stopped compiling
with clang. Fix that.

Test Plan: fbmake runtests (clang and gcc)

Reviewed By: lucian@fb.com

Subscribers: mathieubaudet, njormrod, bmatheny

FB internal diff: D1618189

(wangle) Use MicroSpinLock

Summary: For great speed

Test Plan:
Before
============================================================================
folly/wangle/test/Benchmark.cpp                 relative  time/iter  iters/s
============================================================================
constantFuture                                             241.19ns    4.15M
promiseAndFuture                                 100.32%   240.42ns    4.16M
withThen                                          44.63%   540.47ns    1.85M
----------------------------------------------------------------------------
oneThen                                                    519.20ns    1.93M
twoThens                                          62.83%   826.41ns    1.21M
fourThens                                         36.80%     1.41us  708.75K
hundredThens                                       1.79%    29.05us   34.42K
----------------------------------------------------------------------------
no_contention                                                4.82ms   207.27
contention                                        62.91%     7.67ms   130.39
============================================================================

After
============================================================================
folly/wangle/test/Benchmark.cpp                 relative  time/iter  iters/s
============================================================================
constantFuture                                             159.79ns    6.26M
promiseAndFuture                                 101.23%   157.84ns    6.34M
withThen                                          41.78%   382.47ns    2.61M
----------------------------------------------------------------------------
oneThen                                                    358.23ns    2.79M
twoThens                                          63.07%   568.00ns    1.76M
fourThens                                         36.89%   971.07ns    1.03M
hundredThens                                       1.76%    20.34us   49.17K
----------------------------------------------------------------------------
no_contention                                                3.75ms   266.75
contention                                        59.83%     6.27ms   159.59
============================================================================

That's a 150% speedup.

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod

FB internal diff: D1617363

Tasks: 5278220

Defer query string parsing from ctor to getQueryParams()

Summary:
Query string parsing uses a lot of CPU, it happens in ctor killing CPU
even in users that are not interested in query string. Move it to
getQueryParams().

Test Plan:
fbconfig folly/test
fbmake runtests_dbg

Reviewed By: ldemailly@fb.com

Subscribers: trunkagent, njormrod, zellux

FB internal diff: D1604973

Tasks: 5304484

Blame Revision: https://phabricator.fb.com/D1455158

Fix opensource build

Summary: D1615707 moved State.h to Core.h, but didn't update Makefile.am

Test Plan: visual

Reviewed By: davejwatson@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1617562

Blame Revision: D1615707

Fix thread local random number generator static issue

Summary:
See https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Thread-Local.html
Thanks to @subodh for finding the first instance of this problem in the
proxygen codebase.

Test Plan:
unit tests, tested proxygen unit tests on my laptop and I don't
get segfaults on program exit now.

Reviewed By: subodh@fb.com

Subscribers: trunkagent, doug, njormrod, subodh

FB internal diff: D1616149

Tasks: 5217022

wangle::detail::FSM

Summary:
spaghetti-monster

Finagle uses a nifty state machine pattern in `Promise.scala`. Each state carries its data with it, then you switch statements with a simple state `cas`, within the functions (which are the transition inputs). See https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Promise.scala#L133-L139 and https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Promise.scala#L604-L635 for example.

I was thinking we could do something similar in C++, though we don't quite have the same luxury of type cases like scala. (Although as an aside I found this really cool paper on implementing type cases in C++, it's kind of evil but very cool. http://www.stroustrup.com/OOPSLA-typeswitch-draft.pdf)

I was looking at having a union of the different state classes, e.g.

union U {
State base;
Done done;
Waiting waiting;
...
};

and then you could use the memoized `dynamic_cast` trick in that paper to make a fairly efficient type case (and fairly readable, depending on how evil you want to get with the macros). However, `dynamic_cast<Done*>(&u.base)` blissfully segfaults. I'm not sure if this is something that should work and it's a compiler bug, or whether trying to (ab)use a union this way is against some arcane C++ rules. @hannesr suggested maybe a variant type might work. We can also do memory mangling on our own if it comes to it - however those are all more advanced techniques to play with at a later optimization time.

So instead, I went for a this-is-context helper base class. The mutable context is just `this`, and you inherit from `FSM`.

The magic macros make it more succint to lay out state transitions. See the tests for examples. Maybe in the future we can get really clever and find a way to generate state machine diagrams from code using this, especially when macros are being used.

Test Plan: unit tests were written and pass

Reviewed By: davejwatson@fb.com

Subscribers: meisner, trunkagent, net-systems@, fugalh, exa, njormrod, hannesr

FB internal diff: D1613497

(wangle) s/State/Core/

Summary:
codemod
`State` is such an overloaded term, and not really the best to describe this backing future/promise object. Yes, it holds the state but it's more than that and it gets in the way of calling the states of the state machines `State`s.

Test Plan: builds and tests pass

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod

FB internal diff: D1615707

Bump version to 12:0

Don't re-create singletons

Summary:
This forbids singleton creation/re-creation after destroyInstances() was called.
Only after reset() is called singletons can be created again.

registrationComplete() behavior is also slightly change. We disallow singleton registration after registrationComplete() is called even in Relaxed mode. Strict mode now only controlls whether singletons can be constructed before registation is complete.

Test Plan: unit test

Reviewed By: chip@fb.com

Subscribers: hphp-diffs@, ps, trunkagent, njormrod, mshneer, lins

FB internal diff: D1605136

Basic tests for EventHandler.

Summary:
[Folly] Basic tests for EventHandler.

Worthwhile adding some tests just for this class since it's rather fundamental. It is already tested indirectly via any number of things that make use of EventBase under the hood, but it's worth having a place for more direct tests.

Test Plan: Unit tests in `folly/io/async/test/EventHandlerTest.cpp`.

Reviewed By: njormrod@fb.com

Subscribers: njormrod, chalfant, dougw

FB internal diff: D1606284

Better estimateSpaceNeeded(double)

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

Reviewed By: mpawlowski@fb.com

Subscribers: njormrod

FB internal diff: D1604761

Blame Revision: D1420588

Go back to a regular mutex

Summary:
D1428504 changed the `detail::State` mutex to be a recursive mutex to get around deadlock in our project, where a promise was being freed within a callback, racing with the mechanics happening while fulfilling the promise in the first place. At least, that's what seemed to be happening. I couldn't easily pull it into gdb because it's a python test.

I made my own test to repro, and it did in fact deadlock:

TEST(Future, DISABLED_promiseDestructedDuringCallback) {
auto p = folly::make_unique<Promise<void>>();
p->getFuture().then([&](Try<void>&&) {
// shouldn't deadlock.
p.reset();
});
p->setValue();
}

However, although this code fixes our project it does not fix this code, which still fails (not with a deadlock, but with a promiseAlreadyFulfilled exception). So whatever our project is doing is a bit more intricate.
I'm not convinced that even allowing this is ok - so I suspect out project is doing something bad. However, I also think it's probably bad to hold the lock while doing the callback so I am presenting this as a fix/compromise.

Test Plan:
unit tests

Reviewed By: hannesr@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, fsilva, davejwatson

FB internal diff: D1604829

Blame Revision: D1428504

Port compilation fixes (1/3)

Test Plan: existing tests

Reviewed By: meyering@fb.com

Subscribers: trunkagent, bmatheny, ranjeeth, njormrod, subodh

FB internal diff: D1605942

Tasks: 5183325

Move static global variable randomDevice inside the scope of the function

Test Plan: Tests under folly passed

Reviewed By: seanc@fb.com

Subscribers: trunkagent, seanc, njormrod

FB internal diff: D1600266

Tasks: 5317470

add per node mutex for emulated futex

Summary:
The emulated futex (not used on Linux) has an optimization to defer
notification until after the bucket mutex has been unlocked, to avoid
lock collisions between the waiter and waker.  That code will have a
use-after-free problem if the waiter's condition_variable has a spurious
wakeup, which is allowed by the spec.  That code also doesn't do
anything about contention between multiple waiters.

This diff adds a mutex to each wait node, relieving the waiters from
having to acquire the bucket lock on wakeup.  Rather than trying to
perform a racy late notification, we just make sure to release the node
lock immediately after calling notify_one, which seems to have the
desired effect.

Test Plan:
1) existing unit tests
2) new unit tests

Reviewed By: delong.j@fb.com

Subscribers: boseant, njormrod

FB internal diff: D1602360

move TEventBaseManager to folly/io/async/EventBaseManager

Summary:
This class isn't thrift specific anymore, especially now that TEventBase->EventBase.
Specific use case in folly: folly/experimental/wangle/concurrent/IOThreadPoolExecutor
EventBaseManager itself needs some work/cleanup, but that is for a later diff
For instance, we might try to push towards only allowing access to the singleton, and towards
removing overrides. i.e. only getEventBase. But that's pending an audit of how people are using it now.

Note that the ProfiledMutex protecting the event base set has been made a regular std::mutex

Test Plan:
compiled thrift/lib/cpp|cpp2, made a pass at fixing forward declarations elsewhere
will let contbuild help me iterate

Reviewed By: hans@fb.com

Subscribers: trunkagent, nli, fbcode-common-diffs@, davejwatson, hero-diffs@, zeus-diffs@, andrewcox, netego-diffs@, alandau, apollo-diffs@, antonl, laser-diffs@, ads-dsp-eng@, darshan, micha, njormrod, panin, hdoshi, scuba-diffs@, bmatheny

FB internal diff: D1590827

Tasks: 5247981

fix flaky test from uninitialized std::atomic

Summary:
std::atomic<bool> default constructor doesn't initialize it to
false, so the flag to end the LifoSem.multi_try_wait test was sometimes
set too early.  This diff fixes that, makes the test more deterministic,
and also fixes a couple of other benign uninitialized values (so that
they won't be used as prototypes for places where it does matter).

Test Plan: unit tests

Reviewed By: mpawlowski@fb.com

Subscribers: njormrod, lovro

FB internal diff: D1604508

Tasks: 5336837

Fix via

Summary: Sometimes you just have to take a step back. :-P

Test Plan: All the unit tests including the one that had been disabled, now pass.

Reviewed By: hannesr@fb.com

Subscribers: meisner, trunkagent, net-systems@, fugalh, exa, njormrod, davejwatson

FB internal diff: D1596368

Tasks: 4920689, 4480567, 5306911

stop prereserving space in toAppend

Summary:
previous change would cause reserving
as much as needed in toAppend for all arguements.
This had bad consequences for appending in a loop,
described here: https://phabricator.fb.com/D1420588#22
Not split the interfaces so that user has to decide

Test Plan: unit tests

Reviewed By: soren@fb.com

Subscribers: trunkagent, njormrod

FB internal diff: D1601614

Tasks: 5303991

wangle-bench gflags

Summary: Because windtunnel quirkloads needs `--json` which is enabled with gflags

Test Plan:
$ wangle-bench --json
{
"%hundredThens" : 28133155.113220215,
"no_contention" : 4842268655.11322,
"%fourThens" : 1495655.1132202148,
"%twoThens" : 882311.3632202148,
"oneThen" : 581053.5507202148,
"-" : 0,
"%withThen" : 559830.8944702148,
"%promiseAndFuture" : 250840.66009521484,
"%contention" : 8074419655.11322,
"constantFuture" : 239916.83197021484
}

Reviewed By: meisner@fb.com

Subscribers: robbert, net-systems@, fugalh, exa, njormrod, davejwatson, jsedgwick

FB internal diff: D1601364

Tasks: 5277907

serial/parallel benchmark

Summary: This is an attempt to see the effect of lock contention in the less-common case where a promise is fulfilled at the same time the future is still being set up. Although this is expected to be off the beaten path, it will still be a good idea to keep an eye on how we improve or worsen perf, when we play with different locking strategies (which I intend to do a lot of in the near term).

Test Plan:
============================================================================
folly/wangle/test/Benchmark.cpp                 relative  time/iter  iters/s
============================================================================
constantFuture                                             249.31ns    4.01M
promiseAndFuture                                 100.88%   247.13ns    4.05M
withThen                                          43.87%   568.30ns    1.76M
----------------------------------------------------------------------------
oneThen                                                    569.62ns    1.76M
twoThens                                          63.46%   897.60ns    1.11M
fourThens                                         39.64%     1.44us  695.90K
hundredThens                                       1.91%    29.75us   33.61K
----------------------------------------------------------------------------
serial                                                       4.97ms   201.21
parallel                                          60.22%     8.25ms   121.18
============================================================================

Reviewed By: jsedgwick@fb.com

Subscribers: meisner, net-systems@, fugalh, exa, njormrod

FB internal diff: D1593010

add emulation of futex() for non-Linux systems

Summary:
Inside the Linux kernel, futex() works by hashing the source
address to a fixed set of wakeup lists.  When using folly on non-Linux
systems we can emulate something similar by using std::mutex and
std::condition_variable.

Emulating futex() using higher-level APIs is less crazy than it sounds,
because the emulated futex still provides the advantages of the real
one: it allows all of the fast-paths of a new synchronization construct
to be inlined; it is space efficient, taking only 1 word and allowing
the caller to encode state into all of the word's bits; and it avoids
system calls unless a thread actually needs to be put to sleep or
woken up.  Think of this as a way of boostrapping something with the
same properties as futex() on platforms that don't expose it publically.
(Presumably these platforms have private APIs that do something similar.)

This diff moves all of the Linux-specific futex stuff into Futex.cpp,
where it is gated by #ifdef __linux__.  It also adds an emulated
implementation.  The emulated futex will be selected by default on
non-Linux platforms, or it can be used on Linux by using an Atom template
type of folly::detail::EmulatedFutexAtomic.  This means, for example,
that you can test MPMCQueue on top of the emulated API by instantiating
a MPMCQueue<ElemType, EmulatedFutexAtomic>.

As a bonus, this refactoring provides a small speed boost by removing
an unnecessary evaluation of the errno macro in the success path of
futexWait.

Test Plan:
1. existing unit tests
2. new unit tests (including tests of Futex users)
3. compile Futex.cpp on OS X (some other build failures still occur)

Reviewed By: delong.j@fb.com

Subscribers: trunkagent, njormrod, yiding, boseant, mssarang

FB internal diff: D1596118

Tasks: 4952724

Move static member inside the scope of the function

Summary: We are seeing crashes which comes from the initialization of the static global variable. This particular variable is used only in a single function that was never invoked. So moving it into the scope of the function will at least solve the problem. The real issue still requires some deep investigation though.

Test Plan: unitest under folly passed

Reviewed By: subodh@fb.com

Subscribers: seanc, njormrod

FB internal diff: D1598048

Tasks: 5316441

detail::MemoryIdler should use Malloc.h's mallctl decl

Summary:
Malloc.h now takes care to declare mallctl properly on platforms
that aren't using weak symbols, so we should just rely on that for
MemoryIdler.cpp.  This is one step toward fixing folly build on OS X.

Test Plan: fbmake runtests

Reviewed By: je@fb.com

Subscribers: yiding, njormrod

FB internal diff: D1596930

Tasks: 4952724

Blame Revision:

Leak folly::SingletonVault

Summary:
This will ensure SingletonVault is always available. It matters for singletons, not managed by folly::Singleton. Singletons in it will actually be destroyed via static SingletonVaultDestructor.

This does the same as D1591270 (which got reverted), but doesn't change destruction order.

Test Plan:
Run tests which were broken by D1591270

Reviewed By: chip@fb.com

Subscribers: njormrod

FB internal diff: D1594898

Fix folly::Singleton to work with objects w/o default constructor

Test Plan:
unit tests

Reviewed By: ostap@fb.com

Subscribers: netego-diffs@, trunkagent, alikhtarov, marccelani, mshneer, zhuohuang, lins, njormrod

FB internal diff: D1560406

Add extra assertions in ExternalUnixAddr::free()

Summary: Memory corruption investigation

Test Plan: fbconfig folly/test:network_address_test; fbmake runtests

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, andrii, njormrod

FB internal diff: D1592539

Tasks: 5230657

Blame Revision: D1575098

Revert "Leak folly::SingletonVault"

Summary:
This reverts commit 3cf88fb680b4b9c47189d1e12699e2c24c7ac38b. It
was timing out our tests. probably static (de)initialization order fiasco related.

Test Plan: watch contbuild, git bisect

Reviewed By: afrind@fb.com

Subscribers: doug, njormrod

FB internal diff: D1593016

Leak folly::SingletonVault

Summary: This will ensure SingletonVault is always available. It matters for singletons, not managed by folly::Singleton. Singletons in it will actually be destroyed via static SingletonVaultDestructor.

Test Plan: unit test

Reviewed By: chip@fb.com

Subscribers: njormrod

FB internal diff: D1591270

add some benchmarks

Summary: For great speed

Test Plan:
$ fbmake opt && _bin/folly/wangle/wangle-bench
============================================================================
folly/wangle/test/Benchmark.cpp                 relative  time/iter  iters/s
============================================================================
constantFuture                                             235.92ns    4.24M
promiseAndFuture                                 100.37%   235.04ns    4.25M
withThen                                          41.97%   562.17ns    1.78M
----------------------------------------------------------------------------
oneThen                                                    539.03ns    1.86M
twoThens                                          64.01%   842.14ns    1.19M
fourThens                                         39.27%     1.37us  728.62K
hundredThens                                       1.82%    29.63us   33.75K
============================================================================

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod

FB internal diff: D1587871

subscriptions

Summary:
I'm not thrilled with this implementation, but it mostly works. The big bummer is enforcing that Observables are held in shared_ptrs, or rather that enforcing that condition is impossible.
The protected constructor / friended dumb make_shared() pattern is clunky, and it'd be really easy for a subclasser to shoot themselves in the foot or even in the face.

It does seem like maybe Observable should be made an interface again, and all these details should live in a subclass (FanoutObservable?) where the restriction are super obvious. For instance, the langtech AudioStream object doesn't need all this crap because it overrides subscribe() without using the observer list, but it subclasses anyways.

I'm noodling another approach that (if it works) will not require the shared_ptr dancing, but will probably have some additional overhead... the observable would have to keep track of the subscriptions itself.

I like the RAII subscriptions, though perhaps subscriptions should be optional as long as it's clear that your subscription will last forever it you opt out of them.

Thoughts?

Test Plan: added unit

Reviewed By: hans@fb.com

Subscribers: rushix, hannesr, trunkagent, fugalh, mwa, jgehring, fuegen, njormrod, bmatheny

FB internal diff: D1580443

add stringVPrintf() and stringVAppendf()

Summary:
This adds versions of stringPrintf() and stringAppendf() that accept
va_list arguments.

This also fixes the existing stringPrintf() functions to properly call
va_end() even when an exception is thrown in stringPrintfImpl().

Test Plan: Included new unit tests for stringVPrintf() and stringVAppendf().

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, doug, net-systems@, exa, njormrod

FB internal diff: D1583675

in thread pools, take factory as shared ptr

Summary: needed for thrift server. if you have some sort of stateful/functional factory and you want to hold on to it, you should be allowed to

Test Plan: compiles with forthcoming thrift diff

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, fugalh, njormrod

FB internal diff: D1584587

expose event base from IOThreadPoolExecutor

Summary:
I'm not 100% sure this is the best way to go about this but I don't hate it either.
I'm going to start seeing how it might fit into tserver - my guess is that some sort Cpp2WorkerFactory which also manages those objects would get plugged in as the thread factory
Haven't fleshed out how this would relate to TEventBaseManager

Test Plan: added unit, starting to play with this in Thrift2 server

Reviewed By: davejwatson@fb.com

Subscribers: alandau, bmatheny, trunkagent, fugalh, njormrod

FB internal diff: D1574660

Bump version to 11:0

(Wangle) Make via behave more like gate

Summary:
Could the problem be that via continues the existing chain of futures,
whereas we actually want to start a new chain?

Is there any particular reason this wasn't implemented like this originally?

Test Plan:
Ran all the unit tests. I hope to try to reproduce the thread issue and
see if this improves things.

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, exa, njormrod, fugalh

FB internal diff: D1500225

Tasks: 4920689

remove get_weak from singleton

Summary:

Test Plan: fbmake runtests, OBC no longer segfaults

Reviewed By: mshneer@fb.com

Subscribers: fbcode-common-diffs@, trunkagent, mcduff, marccelani, hitesh, mshneer, njormrod, lins

FB internal diff: D1573880

Fix compiler warning in Subprocess

Summary: I'm going to have hhvm depend on Subprocess, found this build error in open source.  I figured the intent was to set r to the return code.  I could also delete the whole thing since it's unused.

Test Plan: Unit tests

Reviewed By: tudorb@fb.com

Subscribers: trunkagent, mwilliams, doug, njormrod

FB internal diff: D1583626

Fix bug and unit test failure in HHWheelTimer

Summary: Some minor bug and a failed test caused by D1578466

Test Plan:
fbconfig thrift/lib/cpp/test:HHWheelTimerTest && fbmake
runtests

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, alandau, bmatheny, njormrod

FB internal diff: D1581949

Use RWSpinLock for Singleton mutex

Summary: We only need exclusive lock when we add items to singletons_. Each SingletonEntry has its own mutex, so it's safe to rely on it for any modifications within individual entries.

Test Plan: Applied D1573880 and ran fbconfig -r servicerouter/client/cpp2 && fbmake runtests

Reviewed By: chip@fb.com

Subscribers: trunkagent, njormrod, hitesh, mshneer

FB internal diff: D1579877

Malloc cannot include ScopeGuard

Summary:
Because we put FBString and Malloc into libgcc, we have to be
careful which dependencies they each have. We cannot include ScopeGuard.
Reorganize the code a bit to avoid the ScopeGuard.

Test Plan: fbconfig -r folly && fbmake runtests

Reviewed By: je@fb.com

Subscribers: trunkagent, sdwilsh, njormrod

FB internal diff: D1580957

Rare bug fix

Summary:
By the birthday paradox, this will fail about once every 8,100
runs. Dropping to 100 with cut that to 1 in 860,000.

Test Plan: fbconfig -r folly && fbmake runtests

Reviewed By: sdoroshenko@fb.com

Subscribers: sdwilsh, njormrod

FB internal diff: D1581238

Bump version to 10:0

fix future executor test

Summary: This should be the last test abusing sleeps.

Test Plan: ran

Reviewed By: hannesr@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1580830

Tasks: 5225808

folly/GroupVarint: fix a clang-caught heap-buffer-overrun

Summary:
Avoid a clang-caught heap-buffer-overrun
and document that the ssse3 decoder requires at least 17 bytes
of readable memory starting at the source pointer.
* folly/GroupVarint.h (decode_simple): Comment out dead code.
(decode)[__SSSE3__]: Add a comment describing this limitation.
* folly/test/GroupVarintTest.cpp (testGroupVarint32):
Include <algorithm> for use of std::max.
Ensure that the buffer we use has length at least 17.

Test Plan:
Now, all tests succeed with clang/asan

Reviewed By: simpkins@fb.com

Subscribers: trunkagent, mathieubaudet, njormrod

FB internal diff: D1579109

Tasks: 5241437

RFC: future executor

Summary:
not necessarily for commit but i was playing around a bit with this today to see what it might look like, so i figured i'd put it up
i assume this shenanigan isn't remotely safe (threadwise) without some extra magic... @fugalh we chatted about this last time i was in mpk a bit.
maybe addFuture could take an executor to make sure the promise is fulfilled on the correct thread, or something.

you'd have to reimplement timeouts via this executor or via futures if you wanted to get them via the futures channel, which makes sense anyway as this could be used with any Executor and not just ThreadPoolExecutor which owns that implementation

also specialized makeFutureTry to take functions that return futures but treat them like they return the contained types, so fulfil() can be used liked then()
this specialization could just as easily be done on fulfil() itself if we wanted.

Test Plan: unit

Reviewed By: davejwatson@fb.com

Subscribers: hannesr, trunkagent, craffert, njormrod, fugalh, bmatheny

FB internal diff: D1566369

fix more flakey tests

Summary: fixed the one brought up in the task, and tweaked another that could theoretically cause problems

Test Plan: ran, though I have not been able to repro the

Reviewed By: njormrod@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1575632

Tasks: 5225808

Set DEFAULT_CATCHUP_EVERY_N to 10 to get more accurate task expiration when busy event base

Summary:
when event base is busy we're timing out tasks too early.
BIG SCARY NOTE: I don't have the thrift knowledge to know if there's sideeffects of this, please let
me know if this change is harmful.

Test Plan:
tested internally

Reviewed By: davejwatson@fb.com

Subscribers: njormrod

FB internal diff: D1578466

Tasks: 4752162

Fix SocketAddress AF_UNIX support

Summary: check external_ vs. AF_UNIX.  Also fix reset() to reset storage_.addr

Test Plan: fbconfig folly/test:network_address_test; fbmake runtests

Reviewed By: soren@fb.com

Subscribers: tudorb, trunkagent, doug, njormrod

FB internal diff: D1575098

Add and fix BUCK files for folly

Summary:
This gets almost all of folly building with buck.  There are a few
cases we don't support yet (custom test wrappers for spooky test
binaries, dlopen-enabled exception tracer binary, etc), but the
vast majority is covered.

Test Plan: built all build targets and ran all tests buck

Reviewed By: sdwilsh@fb.com

Subscribers: tjackson, sdwilsh, fugalh, njormrod

FB internal diff: D1577256

Tasks: 5055879

expose the class_name in an efficient way

Summary:
Add a class_name method, which doesn't need to throw/catch
regardless how the exception is captured.

Test Plan: exception_wrapper_test

Reviewed By: mshneer@fb.com

Subscribers: njormrod

FB internal diff: D1543596

Tasks: 5025089

Blame Revision:

Disable failing wangle test

Summary:
Under moderate load, this part of the test would fail. When
there is resource contention, it is quite possible that the timeout will
be exceeded. A further reduction of the time spread will render this
test next to useless.

Moderate load can be as little as running all of folly's tests at once,
which is something that our testing infrastructure does quite
frequently.

fbconfig -r folly
fbmake runtests

Test Plan:
fbconfig -r folly && fbmake runtests

Reviewed By: hannesr@fb.com

Subscribers: sdwilsh, fugalh, njormrod

FB internal diff: D1576570

Tasks: 5225808

Fix some folly memory leaks found with clang:dev + asan

Summary:
Reverts the revert of the small_vector and test parts of D1569246.
I'm saving the SocketAddress fix for later, because it caused problems
and needs more research.

Test Plan:
unit tests with clang:dev/asan

Reviewed By: njormrod@fb.com

Subscribers: mathieubaudet, philipp, meyering, njormrod

FB internal diff: D1575574

Blame Revision: D1575190

update thrift to use managed connection

Summary:
Use the new managed connection code in folly.  Cleans things up a fair bit

The only catch was the current ConnectionManager code uses raw pointers, thrift expects shared_ptr so the request object can keep the channel around until the requests are finished

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

Reviewed By: afrind@fb.com

Subscribers: trunkagent, njormrod, doug, fugalh, alandau, bmatheny, dcsommer, afrind

FB internal diff: D1519923

Tasks: 5002343

Revert "Fix folly memory leaks found with clang:dev + asan."

Summary: This reverts commit 2c726dcf86bb176fb3695739a3d8bca2f95c41e6.

Test Plan: build it

Reviewed By: soren@fb.com

Subscribers: woo, mathieubaudet, njormrod

FB internal diff: D1575190

de-flake tests

Summary: make these more serialized / event based so they don't get flakey under high load

Test Plan:
ran under load - caveat: i was not able to repro the flakiness @njormrod reported
but by inspection these should be fine

Reviewed By: njormrod@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1574640

Tasks: 5225808

Fix folly memory leaks found with clang:dev + asan.

Summary: I tried running folly/test with clang:dev and asan and found these leaks.

Test Plan:
unit tests with clang:dev/asan

Reviewed By: davejwatson@fb.com

Subscribers: davejwatson, trunkagent, mathieubaudet, njormrod, meyering, philipp

FB internal diff: D1569246

user-defined expirations

Summary:
Couple of notes:
1. is it a bummer not to have per-task callbacks of some kind? the interfaces set up here only tell you that some task expired, not which one expired. TM calls back with the Runnable object. is that useful?
2. std::chrono::* business is frustratingly verbose, but the safety/explicitness is nice. Not sure how I feel overall.
3. perhaps expirations should be given in microseconds even if we don't think we can accurately accomplish that

Test Plan: added unit

Reviewed By: hans@fb.com

Subscribers: fugalh, njormrod, bmatheny

FB internal diff: D1563520

Fix fbthrift build

Summary: Mcrouter open source build is failing because Codel is missing in fbthrift.

Test Plan: visual

Reviewed By: davejwatson@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1572122

Blame Revision: D1566128

fix unittest

Summary: Looks like the test explicitly looks for InvalidAddressFamilyException.  I don't think any users are depending on this particular error type either way, I just switched it to InvalidAddressFamilyException

Test Plan:
unit tests

Reviewed By: ldbrandy@fb.com

Subscribers: doug, njormrod

FB internal diff: D1570363

Tasks: 5153819