- 20 May, 2015 19 commits
-
-
Brian Watling authored
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
-
Dave Watson authored
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
-
James Sedgwick authored
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
-
Tudor Bosman authored
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
-
Alan Frindell authored
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
-
James Sedgwick authored
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
-
Hannes Roth authored
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
-
Hannes Roth authored
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
-
Hannes Roth authored
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
-
James Sedgwick authored
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
-
James Sedgwick authored
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
-
James Sedgwick authored
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
-
Pavlo Kushnir authored
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
-
James Sedgwick authored
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
-
Igor Sugak authored
Summary: I tried to fix this for default glibc but there are many mismatched-tags inside glibc itself. gcc-4.9-glibc-2.20 does not have such issue, using it. ```lang=bash % fbconfig --clang --with-project-version clang:dev --extra-cxxflags=-Wmismatched-tags --extra-cxxflags=-ferror-limit=0 --platform-all=gcc-4.9-glibc-2.20-fb -r folly % fbmake dev -j55 2> err % perl -n -E 'm/\[-Werror,-Wmismatched-tags\]$/ && print' err | sort -u ./folly/experimental/fibers/TimeoutController.h:52:3: error: 'TimeoutHandle' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags] folly/experimental/fibers/TimeoutController.h:52:3: error: 'TimeoutHandle' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags] folly/experimental/JSONSchema.cpp:65:10: error: class 'ValidationContext' was previously declared as a struct [-Werror,-Wmismatched-tags] ./folly/futures/detail/Core.h:76:1: error: 'Core' defined as a class template here but previously declared as a struct template [-Werror,-Wmismatched-tags] ./folly/futures/Future.h:392:10: error: class 'Promise' was previously declared as a struct [-Werror,-Wmismatched-tags] ./folly/futures/Future.h:45:1: error: 'Future' defined as a class template here but previously declared as a struct template [-Werror,-Wmismatched-tags] ./folly/futures/Future-pre.h:137:1: error: struct 'Timekeeper' was previously declared as a class [-Werror,-Wmismatched-tags] ./folly/futures/Future-pre.h:23:18: error: struct template 'Promise' was previously declared as a class template [-Werror,-Wmismatched-tags] ./folly/futures/Future-pre.h:43:18: error: struct template 'Core' was previously declared as a class template [-Werror,-Wmismatched-tags] ./folly/futures/Promise.h:26:20: error: class template 'Future' was previously declared as a struct template [-Werror,-Wmismatched-tags] ./folly/futures/Timekeeper.h:23:18: error: struct template 'Future' was previously declared as a class template [-Werror,-Wmismatched-tags] ./folly/futures/Timekeeper.h:44:1: error: 'Timekeeper' defined as a class here but previously declared as a struct [-Werror,-Wmismatched-tags] ./folly/Singleton.h:378:10: error: class template 'SingletonHolder' was previously declared as a struct template [-Werror,-Wmismatched-tags] ./folly/wangle/ssl/SSLCacheOptions.h:17:1: error: 'SSLCacheOptions' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags] ./folly/wangle/ssl/SSLContextManager.h:29:1: error: class 'SSLCacheOptions' was previously declared as a struct [-Werror,-Wmismatched-tags] ./folly/wangle/ssl/SSLContextManager.h:32:1: error: class 'TLSTicketKeySeeds' was previously declared as a struct [-Werror,-Wmismatched-tags] % perl -n -E 'm/\[-Werror,-Wmismatched-tags\]$/ && print' err | sort -u | wc -l 16 ``` Updated manually. In all cases preferred tag from definition. Test Plan: Compile with clang dev and gcc-4.9-glibc-2.20-fb and see fewer errors: ```lang=bash % fbconfig --clang --with-project-version clang:dev --extra-cxxflags=-Wmismatched-tags --platform-all=gcc-4.9-glibc-2.20-fb -r folly % fbmake dev -j55 ``` Reviewed By: markisaa@fb.com, meyering@fb.com Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2066327 Signature: t1:2066327:1431471232:c65c2827398ba29a4022cc6a5647fac2b3aad717
-
James Sedgwick authored
Summary: as above. I'm torn on whether to sugar "*this = SharedPromise<T>" as SharedPromise<T>::reset() If I see another use case I'll probably do it Test Plan: unit Reviewed By: hans@fb.com Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2064449 Signature: t1:2064449:1431476780:7113366b11feaf9e8a4ea1dc60fbafb36dd46ac5
-
James Sedgwick authored
Summary: I tried two "smart" ways (deriving from Promise, encapsulating a Promise) and got nothing but trouble. The KISS principle is applied with gusto in this diff. Test Plan: unit, integrating in 3+ places in separate diffs Reviewed By: hans@fb.com Subscribers: craffert, trunkagent, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2035528 Signature: t1:2035528:1431393438:4e554cd30fa531d75b9267dccaade6dc516f2b15
-
Adam Simpkins authored
Summary: Make addFunctionInternal() publicly available, as an overloaded version of addFunction(). This allows users to add functions with a specified poisson distribution. This allows us to deprecate our internal legacy version of FunctionScheduler, and replace it with the folly version. Test Plan: Confirmed all unit tests still pass. Reviewed By: ldbrandy@fb.com Subscribers: jwatzman, doug, net-systems@, exa, folly-diffs@, yfeldblum, chalfant FB internal diff: D2051699 Signature: t1:2051699:1431379841:f3547d1ed371503b0bf91b509a4ef03e881aa991
-
Woo Xie authored
Summary: when any system resource limit is reached, proxygen reduces the number of idle downstream sessions to accomodate new ones. Test Plan: canarying on edge241.01.ams3. Here is the number of idle connection closed during pre load shedding stage. https://www.facebook.com/pxlcld/ml7J Reviewed By: afrind@fb.com Subscribers: alandau, noamler, fugalh, bmatheny, folly-diffs@, jsedgwick, yfeldblum, chalfant, xning, alexkr FB internal diff: D2030988 Tasks: 5698711 Signature: t1:2030988:1431369559:ce7328d51c7fd0afa7e9e5c19b0c66736d01fee1
-
- 12 May, 2015 21 commits
-
-
Praveen Kumar Ramakrishnan authored
-
Stepan Palamarchuk authored
Summary: In most cases user is not aware of ASAN and fiber stack problem, thus if the stackSize is specified we're not detecting ASAN and probably will crash. And thus it doesn't seem like a good idea to make it a user responsibility to detect ASAN. Test Plan: tests Reviewed By: andrii@fb.com Subscribers: alikhtarov, folly-diffs@, yfeldblum, chalfant FB internal diff: D2058741 Tasks: 7016680 Signature: t1:2058741:1431131082:9a41eb40d756c9c7af0632f7ecd55c17d10bb189
-
Hannes Roth authored
Summary: I figured it would make sense to implement all the collect* functions using a shared_ptr<Context>, instead of doing our manual reference counting and all that. Fulfilling the promise in the destructor seemed like the icing on the cake. Also saves some line of code. Test Plan: Run all the tests. Reviewed By: hans@fb.com Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2015320 Signature: t1:2015320:1431106133:ac3001b3696fc75230afe70908ed349102b02a45
-
Tom Jackson authored
Summary: Since the old one is weak and slow. Test Plan: Unit tests Reviewed By: ott@fb.com Subscribers: trunkagent, maxime, folly-diffs@, yfeldblum, chalfant FB internal diff: D2052630 Tasks: 6998080 Signature: t1:2052630:1431015271:bc90ccf99941902cd4bd43a0980238c616e66abf
-
Alexey Spiridonov authored
Summary: In order to create an EventBase'd Suprocess class, I'd like to be able to manage the lifetime of pipes independently of the lifetime of the process. To this effect, I factored out basic Pipe handling, and provided a function that detaches the pipe vector from the Subprocess object. #6996492 a push-blocking test is broken in trunk Test Plan: added a unit test, fbconfig -r folly && fbmake runtests && fbmake runtests_opt Reviewed By: dancol@fb.com Subscribers: yfeldblum, chalfant, dancol, wez, anarayanan, trunkagent, net-systems@, njormrod, folly-diffs@ FB internal diff: D1699969 Signature: t1:1699969:1430975299:30d291ab7fcc555edddf098b33095a5b29500e76
-
Alexey Spiridonov authored
Summary: This almost always indicates a double-close bug, or a similarly nasty logic error. I don't dare make it a check, we may have some code running in production which would be broken by the CHECK, but this should give us early warning of any such bugs. Test Plan: ``` fbconfig folly/test:file_test folly/test:file_util_test fbmake runtests && fbmake runtests_opt ``` This test used to pass until @tudorb made me remove it due to worries about death tests messing with (currently absent) multi-threading: ``` + +void testDoubleClose() { + File f("/dev/null"); + checkUnixError(close(f.fd())); // This feels so... wrong! + // The destructor will now try to double-close. +} + +TEST(File, DCHECKDoubleClose) { +#ifndef NDEBUG + // This test makes no sense otherwise, since this is a DCHECK. + EXPECT_DEATH(testDoubleClose(), "double-close-FD"); +#else + // That sound you hear is millions of lemmings falling to their doom. + testDoubleClose(); +#endif +} ``` Reviewed By: tudorb@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant FB internal diff: D2055610 Signature: t1:2055610:1431048270:a469d5c1f8182ffb74700908faa022e9613ed383 -
Adam Simpkins authored
Summary: Use std::chrono::steady_clock instead of clock_gettime(CLOCK_MONOTONIC). In particular this fixes the build on Mac OS X, which doesn't have CLOCK_MONOTONIC. This also updates the code to use steady_clock::time_point correctly, instead of using a raw milliseconds value for time since the epoch. Test Plan: Included unit tests, which were copied over from the legacy internal Facebook (non-folly) version of this code. Reviewed By: ldbrandy@fb.com Subscribers: jwatzman, doug, fbcode-common-diffs@, net-systems@, exa, folly-diffs@, yfeldblum, chalfant FB internal diff: D2051557 Signature: t1:2051557:1431019654:ee76cfcf8318cc3d8a8d1522b3fc97f08831ecf4
-
Josh Watzman authored
Summary: Per discussion on D2040509 this is better. Test Plan: Still builds. Reviewed By: yfeldblum@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant FB internal diff: D2051099 Signature: t1:2051099:1430949575:cc167b57f2d6ff42a73dee4e65d22d04932bb279 Blame Revision: rFBCODE9bdb427be1ef80b612e4f364db7809c6351cfe1c
-
Josh Watzman authored
Summary: OS X doesn't support constructor init priorities, at all. AIUI, it's a limitation of their actual binary format and loader, not just a tooling/compiler limitation. This particular usage appears to just be for for logging/bug-finding purposes, so it looks like just removing the priority on OS X isn't the end of the world? Test Plan: g++-4.9 on OS X compiles this file now. Reviewed By: njormrod@fb.com Subscribers: ldbrandy, jdelong, folly-diffs@, yfeldblum, chalfant FB internal diff: D2040557 Signature: t1:2040557:1430975025:73f817b5d19a18dca6b19ba783dbea99192cbc41
-
Ming Zhao authored
Summary: Signed-off-by: Nicholas Ormrod <njormrod@fb.com> Test Plan: fbconfig -r folly && fbmake runtests Reviewed By: yfeldblum@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant FB internal diff: D2042952 Tasks: 6783581
-
YM CHEN authored
Summary: Signed-off-by: Nicholas Ormrod <njormrod@fb.com> Test Plan: fbconfig -r folly && fbmake runtests Reviewed By: yfeldblum@fb.com Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2043151 Tasks: 6783581
-
Josh Watzman authored
Summary: This is for OS X; there is apparently some difference between its types and Linux's typical types, causing incomopatibilities between a `long int` and a `long long int`. These two explicit template instantiations fix the issue. Test Plan: g++-4.9 on OS X compiles these files now. Reviewed By: lucian@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant FB internal diff: D2040509 Signature: t1:2040509:1430516624:9db8146b7824c0d09bac418a10a5f54451cdd5db
-
Sergey Doroshenko authored
Summary: I just had topaggr built from trunk crash with https://phabricator.fb.com/P19825084. It seems that placing `FOLLY_DISABLE_ADDRESS_SANITIZER` next to the function definition has no effect. Though what's strange, https://phabricator.fb.com/D2036280 test plan says the false-positive crashes stopped after that diff. Have we run the tao script on the latest revisions of that diff? Anyway, clang/gcc docs clearly say the attributes belong to declarations, not definitions, so let's do that. Test Plan: Compiled, unit tests. Reviewed By: aap@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant, soren FB internal diff: D2042149 Signature: t1:2042149:1430681824:aea21b9a1fcddfd5585180ba7f526c3a6ee0c8bf
-
James Sedgwick authored
Summary: A client example to match telnet server. Required a couple additions: * future result when socket actually connects, similar to netty * clients support IOThreadPoolExecutor groups * a pipeline stage to make sure everything runs in the right eventbase thread. Test Plan: fbconfig follg/wangle/example/telnet && fbmake dbg telnet_server telnet_client Reviewed By: hans@fb.com Subscribers: doug, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2010289 Signature: t1:2010289:1430766232:65c6f946e454000f6ea9f41b49197ddbeea5ba3f
-
James Sedgwick authored
Summary: similar to https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/telnet Test Plan: fbconfig folly/wangle/example/telnet; fbmake dbg _bin/folly/wangle/example/telnet_server --port=8080 telnet localhost 8080 Still a couple sharp edges: * No easy way to wait for ServerBootstrap termination. * Pipelines always have to call attachReadCallback * a bunch of missing methods in pipeline still, like channelActive Reviewed By: hans@fb.com Subscribers: doug, fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D1959172 Signature: t1:1959172:1427993978:463f237036996451187e3ef3983cf2b4e89685ef
-
James Sedgwick authored
Summary: Leave the important headers visible. Opens the door for decent inline docs. Test Plan: unit Reviewed By: hans@fb.com Subscribers: fugalh, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2036799 Signature: t1:2036799:1430749004:db5e58655c27b96826549849722fe962b9ae3985
-
James Sedgwick authored
Summary: Compiling folly/futures:futures-test, this saves 15% (dbg) and 7% (opt) Compiling all of folly/futures, it's 7% ish for each Main blocker right now is that this generates a spew of deprecated warnings from calls to core_->(de)activate() from Future::(de)activate(). Can the deprecations be moved up to the Future methods instead? Also had to fix willEqual for Future<void> which was borked Test Plan: compiles Reviewed By: hans@fb.com Subscribers: trunkagent, folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2021028 Signature: t1:2021028:1430749114:1dd78af47ea91aa5e67929a5884b66ca0c8ae2d8
-
Nicholas Ormrod authored
Summary: @markisaa, @ldbrandy: stdarg.h is for ellipses arguments, ##...##, which this file does contain. The pull request indicates that this header is required for windows. Given that adding it doesn't hurt, and should be there anyways, I'd say go on this pull request. Fixed a fatal error when compiling folly for HHVM Signed-off-by:Nicholas Ormrod <njormrod@fb.com> Test Plan: contbuild Reviewed By: markisaa@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant, ldbrandy, markisaa FB internal diff: D1999557 Tasks: 6783581 Signature: t1:1999557:1429220813:0580882b8a55d86f51cdd602d2d152920d368b75
-
Andre Pinto authored
Summary: Fiber::init() method modifies all the bytes in the fiber's stack in order to produce a high watermark of stack memory usage. This behavior generates ASAN errors, as it modifies stack red zones. For that reason, ASAN is disabled for that particular method. Test Plan: Unit tests Reviewed By: alikhtarov@fb.com Subscribers: folly-diffs@, yfeldblum, chalfant FB internal diff: D2036280 Tasks: 6861962 Signature: t1:2036280:1430439550:e156e0e06fae3615d9d9204e99acaf3072bbfafd
-
Hannes Roth authored
Summary: None of these functions should be templated with `class Executor`. Except `then(Executor, Args...)` because otherwise the compiler gets confused. This was the combination that worked for both Clang and GCC, don't ask me why. I'm assuming this puts it on a low priority... I think this is also OK, because `setExecutor` takes an actual `folly::Executor`, so even `then(Executor, Args...)` won't just work for any `Executor`. Test Plan: Run all the tests. Reviewed By: jsedgwick@fb.com Subscribers: folly-diffs@, jsedgwick, yfeldblum, chalfant FB internal diff: D2036912 Tasks: 6838553 Signature: t1:2036912:1430493088:44f2ffe146298c3f978ac27a45b9b2e33b2b0422
-
Sean Cannella authored
Summary: Address another Android initialization crash by delaying initialization of the EorBio method until first AsyncSSLSocket construction. Test Plan: existing tests Reviewed By: pgriess@fb.com Subscribers: net-systems@, ssl-diffs@, folly-diffs@, yfeldblum, chalfant, #csti FB internal diff: D2036329 Tasks: 6925575, 6925570 Signature: t1:2036329:1430444665:a3201f90860a34808a3cf3b42d530608c8a619a8
-
