- 27 Apr, 2018 2 commits
-
-
Yedidya Feldblum authored
Summary: [Folly] Use `is_invocable_r` in `FunctionRef` v.s. reimplementing it. Reviewed By: ot Differential Revision: D7769745 fbshipit-source-id: 3cb7bf9908cc6e93c7d19ace9a91c69ba14cdfae
-
Mingtao Yang authored
Summary: OpenSSL 1.1.0 renamed and deprecated X509_CRL_get_lastUpdate -> X509_CRL_get0_lastUpdate along with X509_CRL_get_nextUpdate -> X509_CRL_get0_nextUpdate Reviewed By: ngoyal, anirudhvr, Orvid Differential Revision: D7782339 fbshipit-source-id: 63f04284bb54da87d4235a02890107db8abaa4b4
-
- 26 Apr, 2018 3 commits
-
-
Igor Sugak authored
Summary: This was exposed by the latest clang with -Wreturn-std-move enabled: ```lang=bash folly/FBString.h:2487:12: error: local variable 'rhs' will be copied despite being returned by name [-Werror,-Wreturn-std-move] return rhs; ^~~ folly/test/FBStringTest.cpp:1294:23: note: in instantiation of function template specialization 'folly::operator+<char, std::char_traits<char>, std::allocator<char>, folly::fbstring_core<char> >' requested here auto test1 = '\0' + std::move(s1); ^ folly/FBString.h:2487:12: note: call 'std::move' explicitly to avoid copying return rhs; ^~~ std::move(rhs) 2 errors generated. ``` Reviewed By: Orvid Differential Revision: D7776805 fbshipit-source-id: f11ae5a1fc416b8838b8ea74d7f6b488f07cab38 -
Dave Watson authored
Summary: Need to also allow calling this function with a writeLock. Reviewed By: magedm Differential Revision: D7477326 fbshipit-source-id: 403e2667a3f77be4c1d7d06dbd5f36218a659abc
-
Chao Yang authored
Summary: The test is intended to verify the handling of trailing space. Reviewed By: yfeldblum Differential Revision: D7761229 fbshipit-source-id: 0196f57e6c76562562ef1b724f6dff1c7bfd5d81
-
- 25 Apr, 2018 7 commits
-
-
Adam Simpkins authored
Summary: Rename folly/Logging.h to folly/GLog.h. This header primarily exists to just include <glog/logging.h>, and it also defines a single `FB_LOG_EVERY_MS()` macro. I plan to move the folly/experimental/logging/ directory to folly/logging/ soon, and I want to avoid confusing between this `Logging.h` header and the separate `folly/logging/` code. Reviewed By: yfeldblum Differential Revision: D7754543 fbshipit-source-id: c91b8016d303cd0fae9e688e8782b22d095a6554
-
Adam Simpkins authored
Summary: D7642870 accidentally broke linking of folly when libunwind is available. It change the code to use the contents of `${FOLLY_LINK_LIBRARIES}` in folly-deps.cmake, but libunwind was added to `${FOLLY_LINK_LIBRARIES}` after folly-deps.cmake was included, in FollyConfigChecks.cmake. This moves the check for libunwind to folly-deps.cmake to fix this issue. All of the other checks for external libraries are already in folly-deps.cmake. Reviewed By: yfeldblum Differential Revision: D7764762 fbshipit-source-id: 922459a7eefcbd92d3d77c02e9c215bb1a5467cc -
Andrii Grynenko authored
Summary: This allows using a keep-alive token in places where Executor* was previously used. Reviewed By: yfeldblum Differential Revision: D7751516 fbshipit-source-id: af2cb31191a78306439408dbee78dcd923492e30
-
Philip Pronin authored
Summary: `PRETTY_TIME_HMS` extends `PRETTY_TIME` by adding additional minutes and hours units which are more useful for human-reporting of time intervals. Reviewed By: yfeldblum Differential Revision: D7762524 fbshipit-source-id: 881936916db182c163a3df14196f4f11fb649527
-
Yedidya Feldblum authored
Summary: [Folly] Avoid using gmock private macros - instead, use only the public interface. Reviewed By: knekritz Differential Revision: D7752463 fbshipit-source-id: 625465e7ec93613869e259fe1fe0b08aee7bb7d0
-
Xiao Shi authored
Summary: This diff adds a method to calculate the amount of memory allocated by F14 sets. It mimics the node structure in `std::unordered_map` to calculate the results. For certain keys and hashers, the libstdc++ implementation of `std::unordered_map` caches a hash code in the node. libcpp seems to do this for everything. https://github.com/gcc-mirror/gcc/blob/9ce5a00d2d3b8b107cb1ca0e23bf1e31a095f9b6/libstdc%2B%2B-v3/include/bits/hashtable.h#L45-L49 https://github.com/llvm-mirror/libcxx/blob/58bcf28c63e0cf2ee5828e7811829c98bd244dda/include/__hash_table#L117 Depends on D7715573. Reviewed By: nbronson Differential Revision: D7728281 fbshipit-source-id: 0aa3ab60c746d3ab6bdb7c879f2f987110e0329d
-
Orvid King authored
Summary: Because not everyone is at C++17 yet. Reviewed By: yfeldblum Differential Revision: D7751672 fbshipit-source-id: bcca4d4da67d56be0217a940144977f1cc98e5a1
-
- 24 Apr, 2018 6 commits
-
-
Orvid King authored
Summary: Add the currency tests to the CMake build so they can be built in open-source. Reviewed By: yfeldblum Differential Revision: D7750783 fbshipit-source-id: a6e7f9490e0b88bcfab8b2aa706e1504f2a28c66
-
Kevin Ventullo authored
Summary: This looked like a copypasta error. Since there is no duration passed in, there is no notion of timeout. Reviewed By: shixiao, Orvid Differential Revision: D7747574 fbshipit-source-id: 279992d237dd0924ea0be9deafab94c1aef48838
-
Yedidya Feldblum authored
Summary: [Folly] Fix autotools build afte removing `folly/Optional.cpp`. Reviewed By: akrieger Differential Revision: D7737170 fbshipit-source-id: 1a9286f240bf5a15ee08b707b69377f8d3cfdb48
-
Anirudh Ramachandran authored
Summary: OpenSSL 1.1.0 uses a fiber-based (makecontext/swapcontext) API to do asynchronous operations. When some operation deep inside the stack calls ASYNC_pause_job, SSL_accept returns -1 with error SSL_ERROR_WANT_ASYNC. OpenSSL chose to use fds to wait on, so after SSL_accept returns, we create an AsyncPipeReader to restart SSL_accept when the pipe becomes readable, which is our indication that the async job processing has finished. Also implemented a test to kick off an async job in a different thread that creates a pipe and gives the read end back to the SSL* before calling ASYNC_pause_job Reviewed By: yfeldblum Differential Revision: D5977514 fbshipit-source-id: 3aba2e45b9357dc28cf7cf785654072f8ba8dd65
-
Matthieu Martin authored
Summary: On top of the recent/big EventBaseLoopController cleanup away from most EventBase internal, this is unecessary Reviewed By: andriigrynenko Differential Revision: D7734236 fbshipit-source-id: df38cc30fc52df929f096fb878bc1a4b6894850a
-
Murali Vilayannur authored
Summary: We don't have a way to get the metadata associated with a given setting name from outside. This is useful to know the expected type associated with a given setting name. Reviewed By: alikhtarov Differential Revision: D7721340 fbshipit-source-id: e9ad07dd03c172f6f2d4bde5164614ca987c4fd8
-
- 23 Apr, 2018 13 commits
-
-
Yedidya Feldblum authored
Summary: [Folly] Use `throw_exception` in `Optional`, which also respects all stated reasons why the `throw` statement is moved to a separate `.cpp` - to outline it and to permit replacement of its implementation with a call to `std::terminate`. Reviewed By: akrieger Differential Revision: D7728129 fbshipit-source-id: 0539f9d16a719b52f5a81b13b5d2ce2b61d36de0
-
Marc Celani authored
Summary: The sorting approach used in TDigest is inefficient because it is not leveraging the fact that there are k sorted subarrays. This diff leverages inplace_merge to improve performance. The cost of merging k digests of size m used to be O(km * log(km)). It is now O(km * log(k)). Reviewed By: anakryiko Differential Revision: D7690143 fbshipit-source-id: 1307db153b3cae0bb952d4b872aede8c40ce292c
-
Kirk Shoop authored
Summary: The issue is that std::swap must have the same type for both parameters but the member .swap() for PolyVal takes Poly and then uses std::swap(*this, that). the fix uses static_cast to change the Poly to a PolyVal for std::swap Reviewed By: ericniebler Differential Revision: D7730948 fbshipit-source-id: 8dd93fc3c86b87938a7c0c12ccb3b5209a593730
-
Marc Celani authored
Summary: Further performance improvements to TDigest by diverging from the algorithm in the paper slightly, but in a manner that does not impact the results at all. Reviewed By: anakryiko Differential Revision: D7687476 fbshipit-source-id: f71884b0fb21c9e78418643b82b099b01e96e4c9
-
Yedidya Feldblum authored
Summary: [Folly] Fix build failures in `folly/io/async/test/AsyncUDPSocketTest.cpp`, which uses private gmock macros to try to override base-class member functions marked `noexcept`. Using private macros belonging to another library is not the way to go. Reviewed By: siyengar Differential Revision: D7728285 fbshipit-source-id: 84c96826f25679dfb8dd0ec5e5985c3cc19f6e3d
-
Marc Celani authored
Summary: I suspect the algorithm in the tdigest paper is slightly off. Instead of setting boundaries at k = 1, 2, 3...d, it sets boundaries at k_last_elem + 1. This results in two issues: 1) It is possible to have more than d elements in the digest. Now, that is no longer possible, and we can properly reserve the right number of elements. 2) Additional floating point operations are computed than necessary. Reviewed By: anakryiko Differential Revision: D7654147 fbshipit-source-id: 131184d456353a9d936c4ed385e2b5e75d468676
-
Aaryaman Sagar authored
Reviewed By: yfeldblum Differential Revision: D7726522 fbshipit-source-id: fa5ad9fc29152b52c5256849c2822885acd49c23
-
Yedidya Feldblum authored
Summary: [Folly] Cut dead reference to `executorLock_` in Futures test - this field was recently removed. Reviewed By: LeeHowes Differential Revision: D7725446 fbshipit-source-id: a522b66da77bbefeb69970bee20feea46dcc72a5
-
Aaryaman Sagar authored
Summary: `folly::lock()` is a deadlock safe way to acquire write locks on many lockables or `folly::Synchronized` objects ``` lock(folly::wlock(one), folly::rlock(two), folly::wlock(three)); ``` This executes the deadlock avoidance algorithm on a write lock for `one` and `three` and a read lock for `two`. ADL lookup is done for the `lock()` function. It can also work on arbitrary lockables and performs better than both `std::lock()` and acquiring the mutexes in order ``` folly::lock(one, two, three); ``` There is a big performance improvement compared to simply acquiring locks in the same order in the presence of contention. The backoff algorithm tries to adjust to contention and block on the mutex that it thinks is the best fit. Benchmarks look promising ``` ============================================================================ folly/test/SynchronizedBenchmark.cpp relative time/iter iters/s ============================================================================ ThreeThreadsPathologicalFollyLock 3.81us 262.24K ThreeThreadsPathologicalStdLock 5.34us 187.28K ThreeThreadsPathologicalOrdered 6.36us 157.28K ThreeThreadsPathologicalCarefullyOrdered 4.21us 237.29K ---------------------------------------------------------------------------- TwoThreadsTwoMutexesOrdered 260.87ns 3.83M TwoThreadsTwoMutexesSmart 161.28ns 6.20M TwoThreadsTwoMutexesPersistent 226.25ns 4.42M ---------------------------------------------------------------------------- TwoThreadsFourMutexesOrdered 196.01ns 5.10M TwoThreadsFourMutexesSmart 196.73ns 5.08M TwoThreadsFourMutexesPersistent 201.70ns 4.96M ---------------------------------------------------------------------------- TwoThreadsEightMutexesOrdered 195.76ns 5.11M TwoThreadsEightMutexesSmart 187.90ns 5.32M TwoThreadsEightMutexesPersistent 199.21ns 5.02M ---------------------------------------------------------------------------- TwoThreadsSixteenMutexesOrdered 203.91ns 4.90M TwoThreadsSixteenMutexesSmart 196.30ns 5.09M TwoThreadsSixteenMutexesPersistent 230.64ns 4.34M ---------------------------------------------------------------------------- FourThreadsTwoMutexesOrdered 814.98ns 1.23M FourThreadsTwoMutexesSmart 559.79ns 1.79M FourThreadsTwoMutexesPersistent 520.90ns 1.92M ---------------------------------------------------------------------------- FourThreadsFourMutexesOrdered 456.04ns 2.19M FourThreadsFourMutexesSmart 391.69ns 2.55M FourThreadsFourMutexesPersistent 414.56ns 2.41M ---------------------------------------------------------------------------- FourThreadsEightMutexesOrdered 392.20ns 2.55M FourThreadsEightMutexesSmart 277.89ns 3.60M FourThreadsEightMutexesPersistent 301.98ns 3.31M ---------------------------------------------------------------------------- FourThreadsSixteenMutexesOrdered 356.36ns 2.81M FourThreadsSixteenMutexesSmart 291.40ns 3.43M FourThreadsSixteenMutexesPersistent 292.23ns 3.42M ---------------------------------------------------------------------------- EightThreadsTwoMutexesOrdered 1.58us 634.85K EightThreadsTwoMutexesSmart 1.58us 634.85K EightThreadsTwoMutexesPersistent 1.56us 639.93K ---------------------------------------------------------------------------- EightThreadsFourMutexesOrdered 1.33us 753.45K EightThreadsFourMutexesSmart 794.36ns 936.34K EightThreadsFourMutexesPersistent 831.68ns 1.21M ---------------------------------------------------------------------------- EightThreadsEightMutexesOrdered 791.52ns 1.26M EightThreadsEightMutexesSmart 548.05ns 1.51M EightThreadsEightMutexesPersistent 563.14ns 2.78M ---------------------------------------------------------------------------- EightThreadsSixteenMutexesOrdered 785.40ns 2.11M EightThreadsSixteenMutexesSmart 541.27ns 1.60M EightThreadsSixteenMutexesPersistent 673.49ns 1.79M ---------------------------------------------------------------------------- SixteenThreadsTwoMutexesOrdered 1.98us 505.83K SixteenThreadsTwoMutexesSmart 1.85us 541.06K SixteenThreadsTwoMutexesPersistent 3.13us 319.53K ---------------------------------------------------------------------------- SixteenThreadsFourMutexesOrdered 2.46us 407.07K SixteenThreadsFourMutexesSmart 1.68us 594.47K SixteenThreadsFourMutexesPersistent 1.62us 617.22K ---------------------------------------------------------------------------- SixteenThreadsEightMutexesOrdered 1.67us 597.45K SixteenThreadsEightMutexesSmart 1.62us 616.83K SixteenThreadsEightMutexesPersistent 1.57us 637.50K ---------------------------------------------------------------------------- SixteenThreadsSixteenMutexesOrdered 1.20us 829.93K SixteenThreadsSixteenMutexesSmart 1.32us 757.03K SixteenThreadsSixteenMutexesPersistent 1.38us 726.75K ============================================================================ ``` Reviewed By: djwatson Differential Revision: D6673876 fbshipit-source-id: b57fdafb8fc2a42c74dc0279c051cc62976a4e07
-
Yedidya Feldblum authored
Summary: [Folly] Avoid magic macros in Futures `FSM` - just use normal C++ types and functions instead. Reviewed By: LeeHowes Differential Revision: D7725582 fbshipit-source-id: 822e4ca6391a37dc4007833c975fe283cfe5105e
-
Yedidya Feldblum authored
Summary: [Folly] Rename function to `tryUpdateState` in Futures `FSM` for clarity. Reviewed By: LeeHowes Differential Revision: D7725949 fbshipit-source-id: ccda21d990dbedfc4d0b86ab7cfb8eb68d93e429
-
Yedidya Feldblum authored
Summary: [Folly] Use RAII `std::lock_guard` pattern in Futures `FSM` and `Core`. Reviewed By: LeeHowes Differential Revision: D7722808 fbshipit-source-id: e8a0d0ec1fee05cd723411f7b07f520dd56cdf22
-
Yedidya Feldblum authored
Summary: [Folly] Let `Future::ensure` and `Future::onTimeout` invoke forwarded callbacks, just as `Future::then` and other callbacks are invoked. Reviewed By: LeeHowes Differential Revision: D7722762 fbshipit-source-id: 52b5fb6a9247d99718de808b0d28abba7dacdbd6
-
- 22 Apr, 2018 3 commits
-
-
Aaryaman Sagar authored
Summary: Currently each of the lock proxies have distinct types and they are not convertible from one to the other, for example the code below does not work ``` auto wlock = sync.wlock(); wlock.unlock(); auto ulock = sync.ulock(); wlock = ulock.moveFromUpgradeToWrite(); ``` Reviewed By: yfeldblum Differential Revision: D7658256 fbshipit-source-id: 1746a67193fc712fd4d4ff2ce41aa295f998211e
-
Yedidya Feldblum authored
Summary: [Folly] Use exchange in `folly/Synchronized.h` as an example and to make the code there slightly shorter. Reviewed By: aary Differential Revision: D7722730 fbshipit-source-id: c594fc96cff11781b60a3848a860454bcf21c3ca
-
Yedidya Feldblum authored
Summary: [Folly] Backport `std::exchange` to `folly/Utility.h`. Reviewed By: aary Differential Revision: D7722731 fbshipit-source-id: a4a68bfb9ec8b356b77f4a73bdadb7f2807d517f
-
- 21 Apr, 2018 5 commits
-
-
Aaryaman Sagar authored
Summary: There was some code that optionally acquired a lock in a shared or exclusive manner based on whether those methods were available for the mutex or not. This was not used anywhere Reviewed By: yfeldblum Differential Revision: D7722906 fbshipit-source-id: b749527c13a1d980134cc23dea586c83a0b65e91
-
Lucian Grijincu authored
Reviewed By: yfeldblum Differential Revision: D7721840 fbshipit-source-id: f816ba58da290e05d257447c42472d5fa99915e3
-
Zhanhui Li authored
Summary: As per title. Closes https://github.com/facebook/folly/pull/827 Reviewed By: Orvid Differential Revision: D7721855 Pulled By: yfeldblum fbshipit-source-id: fe335dcfa83b4db04616e33e353fea52ebb2bbf2
-
Xiao Shi authored
Summary: D7544180 introduced the `getAllocatedMemorySize` method. This diff adds it for platforms where SSE2 instructions are not available. Reviewed By: nbronson Differential Revision: D7715573 fbshipit-source-id: af35f2dedf4a479895163d9dc18795ba397860f7
-
Giuseppe Ottaviano authored
Summary: `Optional` is often used for arguments and return values, and when the function is inlined it is important to be able to perform optimizations such as constant folding. `launder` forces a load on every access to the `Optional` in GCC, making it unsuitable for small hot functions. This is not specific to the `asm` trick we use to backport `launder` to pre-GCC7: the same code is generated in GCC7 with the builtin `std::launder`. `launder` is needed for correctness, as replacing an object that contains const or reference members in the same storage is UB. However, it seems to be a benign UB that real compilers don't take advantage of. In fact, the implementation of `std::optional` in both libstdc++ and libc++ does not launder the storage: https://github.com/gcc-mirror/gcc/blob/20d1a0756a0cf5072d0cdf3d2adab00063c224a7/libstdc%2B%2B-v3/include/std/optional#L881 https://github.com/llvm-mirror/libcxx/blob/8dd2afa20a01ee70e1a49c15de3de343aa8aa7d6/include/optional#L295 So it should be safe to follow these implementations and recover the perf hit. Reviewed By: luciang Differential Revision: D7689228 fbshipit-source-id: 8283de56b0934583773a0d19f315ae7a8d556e8c
-
- 20 Apr, 2018 1 commit
-
-
Matthew Tolton authored
Differential Revision: D7663240 fbshipit-source-id: d7025eb220ff3f87b05988090297573377ca009a
-
