- 28 Jul, 2020 11 commits
-
-
Harrison Xu authored
Summary: Adding a new method `ConcurrentHashMap::erase_key_if`. This is a more general form of `erase_if_equal`, which allows arbitrary predicates to be evaluated against the existing value type, rather than simple equality. `erase_key_if` was chosen as a name to avoid confusion with `std::erase_if`. Reviewed By: magedm Differential Revision: D22775217 fbshipit-source-id: 151975216d5d4288ec4e88b81f6a8d17a091e8f0
-
Cooper Lees authored
Summary: - I find the ability to make a branch and play with CI on GitHub super handy - Removing the `- master` limitation gives me this ability Reviewed By: yi-xian Differential Revision: D22771835 fbshipit-source-id: 8e8839cb860ab4d1dfa0dda590afaf165127f60d
-
Nick Terrell authored
Summary: Fix 1-byte buffer overrun when parsing the string "-". Reviewed By: mhlakhani Differential Revision: D22695995 fbshipit-source-id: 9d1834c068fc3889a514b77d53d626eb6f72b6c6
-
Eric Sun authored
Summary: In addition to `folly::fibers::Semaphore` which only accepts single token increment/decrement. `folly::fibers::BatchSemaphore` is able to accept batch tokens Differential Revision: D21874795 fbshipit-source-id: 1d4c62bdb079c058529cd917078d81d09d585084
-
Eric Sun authored
Summary: * Implement `SemaphoreBase` which is able to accept batch tokens, most of the logic is copy-pasted from `folly::fibers::Semaphore` with batch token as parameter * This serves as base object which is not public accesseble * BatchSemaphore which is able to accept batch tokens and Semaphore will use `SemaphoreBase` as a fundation Differential Revision: D21874699 fbshipit-source-id: 2536284a2480f2972bd00010833de49bcd5304b2
-
Cooper Lees authored
Summary: - Replace deprecated method - Stops spam to my console as I run with show deprecation warnings Reviewed By: yi-xian Differential Revision: D22776372 fbshipit-source-id: d29193e4c4c26d7facfabf9038dcb33c1af92434
-
Nathan Bronson authored
Summary: MSVC's maintains an intrusive linked list of iterators for debugging purposes in some build configurations, which means that F14MapFallback's hacky conversion from unordered_map::local_iterator to unordered_map::iterator doesn't work. Fortunately, on that platform local_iterator and iterator are the same type, so no hack is needed. Reviewed By: Orvid Differential Revision: D22776318 fbshipit-source-id: 80283c4c451afffe522e55e47cd94971126a6fa6
-
Misha Shneerson authored
Summary: we should report the name of the executore/threadpool that is saturated. propagate names of the executor/threadpool onto the queue we are monitoring. Reviewed By: andriigrynenko Differential Revision: D20773871 fbshipit-source-id: f7f78edd62d515cca19e30a63773180404843c1b
-
Misha Shneerson authored
Summary: as titled The issue here was that we were clearing out the value of current rctx from TLS, then calling `onUnset`. So calling `RequestContext::get` from within the `onUnset` callback resulted in returning the default global RCTX. Reviewed By: yfeldblum, zhxchen17 Differential Revision: D22750092 fbshipit-source-id: 509676d047cf6aec05d08ff3bf656d6d1558fbf5
-
Cooper Lees authored
Summary: - Make OpenR build all deps from source until we remove fbzmq as a dep - Allow a project to move it's Open Source CI forward to an alternative version of ubuntu via a new `--ubuntu-version` parameter Reviewed By: wez Differential Revision: D22768987 fbshipit-source-id: 07205efbd0c87a702638cf30b84a2850d064fa8e
-
Igor Sugak authored
Reviewed By: andrewjcg Differential Revision: D22743063 fbshipit-source-id: 1da870027c92b11509056769626ed1f442d1b426
-
- 27 Jul, 2020 1 commit
-
-
Yedidya Feldblum authored
Summary: [Folly] Move the ubuntu build script to 18.04 from 14.04 and the boost default dep to 1.65.1. Reviewed By: fredemmott Differential Revision: D22779335 fbshipit-source-id: 61be6ef8f3cefa05a8d016a061cbc42605215711
-
- 26 Jul, 2020 3 commits
-
-
Zeyi (Rice) Fan authored
Summary: `SDKROOT` is a requirement if we manually specify the location of the compiler on macOS. Otherwise it wouldn't be able to find the system libraries headers. Reviewed By: wez Differential Revision: D22577887 fbshipit-source-id: 98140e6f9e564d665db085d21023986b240b3732
-
Zeyi (Rice) Fan authored
Summary: Original commit changeset: c6f013565680 Redo D22417488 (https://github.com/facebook/folly/commit/43d80f110b181dd7f72f0f935322a58f9cbb5147), with D22577887 fixing open source CI builds Reviewed By: wez Differential Revision: D22577884 fbshipit-source-id: 0c94483e05715493859d29bc2b58f0847a95826b
-
Flier Lu authored
Summary: The upstream [liburing](https://git.kernel.dk/cgit/liburing/tree/src/include/liburing.h) has changed to use ```extern "C" ```, we must remove the duplicated `extern "C"`. Pull Request resolved: https://github.com/facebook/folly/pull/1416 Differential Revision: D22752570 Pulled By: yfeldblum fbshipit-source-id: fa62d8e462e04676af6d563225455400d7e83c4b
-
- 25 Jul, 2020 4 commits
-
-
Cooper Lees authored
Summary: - OpenR building has been broken for quite awhile and it seems this is the main cause Example CI Failure: https://github.com/facebook/openr/runs/631232675?check_suite_focus=true Reviewed By: wez Differential Revision: D22737174 fbshipit-source-id: 31d44c36d495295d30fe3ddc81991dafed100703
-
Misha Shneerson authored
Summary: We should also use saturation detector on queues fronting CPUThreadPoolExecutor. Reviewed By: andriigrynenko Differential Revision: D20873689 fbshipit-source-id: 25ffc4cf62ddb222ede4f983f88a1c6545a0d4a5
-
Robin Cheng authored
Summary: The pthread_create redefinition also overrides the TSAN-specific pthread_create. This diff deletes this test because the test itself is of little value - see discussion in this diff. Reviewed By: yfeldblum Differential Revision: D22735273 fbshipit-source-id: a23089654697b85698f226b1110af3ed1a0b7fce
-
Robin Cheng authored
Summary: The test forgot to join the pthread. Reviewed By: yfeldblum Differential Revision: D22743458 fbshipit-source-id: 02231ce1e915b9f8679378eaf2ec18dc5dd67280
-
- 24 Jul, 2020 7 commits
-
-
Lewis Baker authored
Summary: Add some coroutine-native versions of the retrying algorithms available for retrying folly::Future-based operations. Adds the following: * `retryWhen()` - This is the fundamental retry algorithm that allows you to specify logic to determine whether to retry and if so when to retry. * `retryN()` - For simple use-cases that immediately retries operations up to N times. * `retryWithExponentialBackoff()` - Retries the operation after an exponentially increasing delay with some random jitter applied. Reviewed By: yfeldblum Differential Revision: D22535487 fbshipit-source-id: c5594d0edfc2414015c345bee79e34f5cdafb789
-
Chad Austin authored
Summary: Building Folly on Fedora 32 fails with a link error, saying SingletonVault::kDefaultShutdownTimeout_ is undefined. I did not investigate, but this constant is only used in one place, so inline it. Reviewed By: yfeldblum Differential Revision: D22713828 fbshipit-source-id: 707797eaef4633e642d07b2b02d9f55187afb99f
-
Lewis Baker authored
Summary: This algorithm takes an awaitable and a duration and cancels the operation and completes with a `FutureTimeout` error if the operation does not complete within the specified duration. This differs from `timed_wait()` in that it still waits for the child operation to complete, even once the timeout has elapsed, rather than just detaching from the operation and letting it complete in the background. This relies on the operation responding to cancellation in a timely manner for the algorithm to have the effect of returning shortly after the timeout elapses. The benefit of waiting for the child operation to complete, however, is that it allows you to safely pass parameters by reference to the child operation and be safe in knowing that the child operation will complete before the awaiting coroutine resumes and potentially destroys those parameters. Reviewed By: yfeldblum Differential Revision: D22199932 fbshipit-source-id: 4f6295a23a860ec52b639eb56a02f8029ffb9009
-
Misha Shneerson authored
Summary: Basic FIFO queues observation hooks. Reviewed By: andriigrynenko Differential Revision: D20773870 fbshipit-source-id: 3f9cbab1b8b10204139ce153d92e08ffb5f6254c
-
Andrew Gallagher authored
Summary: The `F14*Fallback.h` headers are meant to be included textually from `F14*.h` headers and currently fail to compile in modular builds, as a) they have references to items defined in their intended enclosing header and b) even if successfully compiled alone would provide conflicting definitions of the `F14*` structures. This diff adds the `FOLLY_F14_VECTOR_INTRINSICS_AVAILABLE` gate in the `F14*Fallback.h` headers so that they won't get compiled when they're not used. Reviewed By: yfeldblum, luciang Differential Revision: D22568097 fbshipit-source-id: a75b3a4a687e3034dd9c4c3f7fd0a41bfd465272
-
Andrew Gallagher authored
Reviewed By: luciang Differential Revision: D22555074 fbshipit-source-id: b853730e5d0dd96b6f94d71e2332653a1a44c9a1
-
Brandon Schlinker authored
Summary: Some build environments will complain that there is no return specified for the two modified functions despite the `CHECK(false)`. Switching to `folly::terminate_with` resolves. Differential Revision: D22659960 fbshipit-source-id: cff7dd1366fab5c2530584b1f57821bc26b672d4
-
- 23 Jul, 2020 3 commits
-
-
Yedidya Feldblum authored
Summary: [Folly] Move `makeAsyncTask` test helpers inline into the test. Reviewed By: ericniebler Differential Revision: D22674219 fbshipit-source-id: 630c84ce153ad2bfb92d38f3d2c955cb3f043799
-
Andrii Grynenko authored
Summary: (Note: this ignores all push blocking failures!) Differential Revision: D22684908 fbshipit-source-id: bb00bf2896880ae6ed5f189110bb13b5abbd80cd
-
Andrii Grynenko authored
Summary: detachOnCancel adapter can be used with Awaitables that don't support active cancellation, but are safely detachable. When the cancellation is requested the adaptor will emit OperationCancelled exception without waiting for the awaitable to complete. This diff also introduces tryAssign helper, similar to Try::operator=, but which handles a case of throwing move constructor. Reviewed By: lewissbaker Differential Revision: D22578847 fbshipit-source-id: cab9998c8c6a709108edefc3d59e6f44792d562f
-
- 22 Jul, 2020 2 commits
-
-
Yedidya Feldblum authored
Summary: [Folly] Add a missing `std::forward` in `makeAsyncTask`. As a matter of policy in folly futures, continuations are invoked with the cv-ref qualifiers (excluding v qualifiers) with which they are passed. Here is a case where the policy was not upheld. Reviewed By: ericniebler Differential Revision: D22672148 fbshipit-source-id: b8dba221914221d390617fa1c69736c5c547e40c
-
Pranav Thulasiram Bhat authored
Summary: The shallow copied child RC is often used to make small changes to the RC for a limited scope of the request. The tracepoint however reports the raw address of the RC as a way to identify the request itself - Therefore we end up reporting different identifiers for what is 'logically' the same request. This diff adds two additional arguments (the rootIds or pointers to the parent RC) to allow bpf programs to pick up this subtlety. Reviewed By: yfeldblum Differential Revision: D22424318 fbshipit-source-id: f669cabca10fa50b8a81fb4b3585d30654207e4c
-
- 21 Jul, 2020 7 commits
-
-
Nathan Bronson authored
Summary: This diff adds heterogeneous lookup support and eraseInto to the fallback (non-SIMD) version of F14 sets, which is used on mobile. std::is_invocable<hasher, const_iterator const&> is no longer evaluated during erase. It also restructures F14MapTest and F14SetTest so that as many of the tests as possible run in the fallback mode. (Note: this ignores all push blocking failures!) Reviewed By: yfeldblum, ot Differential Revision: D21489440 fbshipit-source-id: 872a250f8a6ec3c9efcd19edb7d9beca196fa865
-
Nathan Bronson authored
Summary: This diff implements efficient heterogeneous lookup, insert, and erase for the fallback (non-SIMD) mode of F14. It relies on internal implementation details of the underlying std::unordered_map implementation that happen to be true for libstdc++, libc++, and MSVC. Extending this technique to F14 sets would be straightforward, but has not been done here. (Note: this ignores all push blocking failures!) Differential Revision: D21408628 fbshipit-source-id: 72e9ddd82a50c02ec762d4b64dc3303848bd0218
-
Lee Howes authored
Summary: getTry reads like a blocking operation but is actually non-blocking. Remove to avoid confusion. (Note: this ignores all push blocking failures!) Reviewed By: yfeldblum Differential Revision: D22494732 fbshipit-source-id: d884d60cc14e2a53cd0657926a885a12b994c1ee
-
Robin Cheng authored
Summary: This is a pretty cryptic race condition, but it works like this: Each thread local instance (i.e. one ThreadLocalPtr) is assigned a unique ID by the static meta. This ID is freed up when the thread local is destroyed, and may then be reused by another newly created thread local. For each thread we keep an array of elements (ElementWrapper), indexed by the thread local ID. Each element has some metadata such as the pointer to the object being cached for that thread and that thread local. There are a few cases where we access a ElementWrapper object: - We write to it under a global lock, when destroying a thread local object (only the i-th element is written to for each thread, if the ID is 'i' for the thread local). - We write to it under a global lock, when reallocating the array of elements for the thread if a new thread local ID exceeds the capacity of the array; this can happen when we are reading the thread local for a thread. - We write to it under a global lock when the corresponding thread is destroyed. - We read from it, *without* any locks, when reading a thread local's value from a thread and the above reallocation case does not occur. The race condition happens in this case: - Thread locals A and B are created - Thread local A is accessed by thread Z, and gets, say ID = 5, the corresponding element E is initialized - Thread local A is destroyed by thread X, and under the global lock, the element E is written to (setting element->ptr = nullptr); ID 5 is released to the list of free IDs. - Thread local B is accessed for the first time by thread Y, and therefore needs to grab an ID; under the global lock, it happens to get ID = 5, and stores that ID into the thread local instance as an atomic int; the store here uses std::memory_order_seq_cst. - Thread local B is then accessed again from thread Z; this time the atomic int ID is loaded with std::memory_order_relaxed, with the resulting value of 5; we then proceed to read element E's ptr value *without any locks*. TSAN reports the last read of element E to be racy with the previous write of element E during thread X's destruction of thread local A. Even though this happened with a mutex operation in between, the final std::memory_order_relaxed causes TSAN to think that the read access was not properly synchronized after the earlier write. This conjecture is confirmed by the following small reproducible test case: ``` TEST(MyTest, Test) { std::mutex mutex; int x = 0; bool written = false; std::atomic<bool> seen{false}; std::thread t0([&] { while (!seen.load(std::memory_order_relaxed)) { } std::cout << x; }); std::thread t1([&] { while (true) { std::lock_guard<std::mutex> guard(mutex); if (written) { seen.store(true, std::memory_order_release); break; } } }); std::thread t2([&] { std::lock_guard<std::mutex> guard(mutex); x = 1; written = true; }); t0.join(); t1.join(); t2.join(); } ``` (This example, when run under TSAN, reports a race condition between "x = 1" and "std::cout << x".) This change makes the load use std::memory_order_acquire so it synchronizes with the store. Should have no performance implications on x86 but I'm not totally confident about that. While we're at it, also changing the allocate() and destroy() functions to use more relaxed memory orders; sequential consistency is unnecessary in these places. Reviewed By: yfeldblum Differential Revision: D22561685 fbshipit-source-id: 0d53925486ef78139ffe71681827b0c0959dd29e
-
Nathan Bronson authored
Summary: libstdc++ versions that don't include N4387 ("perfect initialization" for pairs and tuples) can't use the two-arg pair constructor as an emplace target when the emplace args don't exactly match the destination types. (libstdc++.so.6.0.22 is the first one that contains the improvement, which corresponds to gcc 6.1.0). This diff guards the optimization added in D21419822 (https://github.com/facebook/folly/commit/7d618e4fde39b44e0952880653e10ec97400583f) with an enable_if test to avoid the problem, and includes the template parameter changes necessary to get the target types to the test site. (Note: this ignores all push blocking failures!) Differential Revision: D21766560 fbshipit-source-id: f8b2a0230504237f976e14b0740bb31bc7a57b77
-
Yedidya Feldblum authored
Summary: [Folly] A test for the `atomic_ref` deduction guide, which permits removal of the preprocessor guard in the definition of `make_atomic_ref`. Some parts of folly still support legacy versions of C++ but we do not necessarily run the tests on legacy platforms. Reviewed By: akrieger Differential Revision: D22635366 fbshipit-source-id: 8961d3465b63875a660d9e83d094ebf0cd64d1df
-
Mark Santaniello authored
Summary: Add a `clear()` API to render the Arena like new, except that previously-allocated blocks are preserved to be reused in the future. (Caveat: we do not reuse "large blocks") Reviewed By: yfeldblum, davidtgoldblatt Differential Revision: D22209898 fbshipit-source-id: c2f27d70ee09855df8c8c6fc6d162fca92b9eac8
-
- 18 Jul, 2020 2 commits
-
-
Yedidya Feldblum authored
Summary: [Folly] Mark invoker `operator()` as `[[maybe_unused]]` when defined in macros. If the macro is used in a `.cpp` but the generated `operator()` is not invoked, the compiler might warn. This can easily happen in the following situation: ``` FOLLY_CREATE_MEMBER_INVOKER(invoke_foo_fn, foo); FOLLY_CREATE_MEMBER_INVOKER(invoke_bar_fn, bar); using invoke_one_fn = std::conditional_t< /* cond */, invoke_foo_fn, invoke_bar_fn>; constexpr invoke_one_fn invoke_on; template <typename T> void go(T& t) { invoke_one(t); } ``` In such a situation, either `invoke_foo_fn::operator()` is seen at a call-site or `invoke_bar_fn::operator()` is seen at the call-site, but not both - one of them is unused, and if the right warnings are enabled, will be warned as unused. Reviewed By: luciang, markisaa Differential Revision: D22570047 fbshipit-source-id: a4caa7a95ab74ea075cf41c26525935f3d9186c0
-
Andrii Grynenko authored
Reviewed By: yfeldblum Differential Revision: D22604684 fbshipit-source-id: 4dedb9c831d0a2137d16bbe0514e00a1c8f77f4a
-