1. 28 Jul, 2020 11 commits
    • Harrison Xu's avatar
      introduce ConcurrentHashMap::erase_key_if · 376d6554
      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
      376d6554
    • Cooper Lees's avatar
      Allow a project to have Actions run on all branches · 93921194
      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
      93921194
    • Nick Terrell's avatar
      Fix 1-byte buffer overrun · 1e3603df
      Nick Terrell authored
      Summary: Fix 1-byte buffer overrun when parsing the string "-".
      
      Reviewed By: mhlakhani
      
      Differential Revision: D22695995
      
      fbshipit-source-id: 9d1834c068fc3889a514b77d53d626eb6f72b6c6
      1e3603df
    • Eric Sun's avatar
      Implement BatchSemaphore which is able to accept batch tokens · 6958370b
      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
      6958370b
    • Eric Sun's avatar
      Implement SemaphoreBase which is able to accept batch tokens · 93cbddb8
      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
      93cbddb8
    • Cooper Lees's avatar
      Remove configparser deprecated method readfp · 07d0effa
      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
      07d0effa
    • Nathan Bronson's avatar
      handle MSVC debug iterator tracking in F14 fallback · 4eb1b242
      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
      4eb1b242
    • Misha Shneerson's avatar
      Saturation detector. Naming the queues. Diff 3/7 · a055d929
      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
      a055d929
    • Misha Shneerson's avatar
      fix accessing current rctx in `RequestData::onUnset` callbacks · df19d44b
      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
      df19d44b
    • Cooper Lees's avatar
      Add new --disallow-system-packages flag to `generate-github-actions` · bcfad25b
      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
      bcfad25b
    • Igor Sugak's avatar
      make JsonMockUtil.h compatible with latest googletest · 1b940536
      Igor Sugak authored
      Reviewed By: andrewjcg
      
      Differential Revision: D22743063
      
      fbshipit-source-id: 1da870027c92b11509056769626ed1f442d1b426
      1b940536
  2. 27 Jul, 2020 1 commit
    • Yedidya Feldblum's avatar
      Move the ubuntu build script to 18.04 · c84aa29a
      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
      c84aa29a
  3. 26 Jul, 2020 3 commits
  4. 25 Jul, 2020 4 commits
  5. 24 Jul, 2020 7 commits
    • Lewis Baker's avatar
      Add retryWhen(), retryN() and retryWithExponentialBackoff() · ba3ee5d7
      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
      ba3ee5d7
    • Chad Austin's avatar
      fix link error on gcc 10 · 7daf90c7
      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
      7daf90c7
    • Lewis Baker's avatar
      Add folly::coro::timeout() algorithm · 008f5538
      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
      008f5538
    • Misha Shneerson's avatar
      Saturation detector. Basic algorithm. Diff 1/7 · 586a200d
      Misha Shneerson authored
      Summary: Basic FIFO queues observation hooks.
      
      Reviewed By: andriigrynenko
      
      Differential Revision: D20773870
      
      fbshipit-source-id: 3f9cbab1b8b10204139ce153d92e08ffb5f6254c
      586a200d
    • Andrew Gallagher's avatar
      Fix `F14*Fallback.h` headers in modular builds · bddd247e
      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
      bddd247e
    • Andrew Gallagher's avatar
      Fix missing headers exposed by modular builds · 98eb49fa
      Andrew Gallagher authored
      Reviewed By: luciang
      
      Differential Revision: D22555074
      
      fbshipit-source-id: b853730e5d0dd96b6f94d71e2332653a1a44c9a1
      98eb49fa
    • Brandon Schlinker's avatar
      Fix platform build error caused by lack of return · 613428df
      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
      613428df
  6. 23 Jul, 2020 3 commits
    • Yedidya Feldblum's avatar
      Move makeAsyncTask test helpers inline into the test · ccd77b85
      Yedidya Feldblum authored
      Summary: [Folly] Move `makeAsyncTask` test helpers inline into the test.
      
      Reviewed By: ericniebler
      
      Differential Revision: D22674219
      
      fbshipit-source-id: 630c84ce153ad2bfb92d38f3d2c955cb3f043799
      ccd77b85
    • Andrii Grynenko's avatar
      detachOnCancel: fix shadow-uncaptured-local warning · 6edefe20
      Andrii Grynenko authored
      Summary: (Note: this ignores all push blocking failures!)
      
      Differential Revision: D22684908
      
      fbshipit-source-id: bb00bf2896880ae6ed5f189110bb13b5abbd80cd
      6edefe20
    • Andrii Grynenko's avatar
      Basic detachOnCancel helper · 88ff31c0
      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
      88ff31c0
  7. 22 Jul, 2020 2 commits
    • Yedidya Feldblum's avatar
      Add a missing forward in makeAsyncTask · 27a0093e
      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
      27a0093e
    • Pranav Thulasiram Bhat's avatar
      Pass rootId in SDT for shallow copied RCs · 85009b3f
      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
      85009b3f
  8. 21 Jul, 2020 7 commits
    • Nathan Bronson's avatar
      add heterogeneous lookup and eraseInto to fallback F14 sets · 74e8af86
      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
      74e8af86
    • Nathan Bronson's avatar
      heterogeneous lookup for F14 map fallback · ce0007aa
      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
      ce0007aa
    • Lee Howes's avatar
      Remove Future::getTry · 5d517eb7
      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
      5d517eb7
    • Robin Cheng's avatar
      Fix a TSAN-reported race condition in ThreadLocal. · 2e45ff8d
      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
      2e45ff8d
    • Nathan Bronson's avatar
      callWithExtractedKey fix for old libstdc++ · 6c21531d
      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
      6c21531d
    • Yedidya Feldblum's avatar
      A test for the atomic_ref deduction guide · 67ed8482
      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
      67ed8482
    • Mark Santaniello's avatar
      Add clear() API to folly::Arena · e2b1569f
      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
      e2b1569f
  9. 18 Jul, 2020 2 commits
    • Yedidya Feldblum's avatar
      Mark invoker operator() as maybe-unused · fdcce5ae
      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
      fdcce5ae
    • Andrii Grynenko's avatar
      Make sure EventBase task destructor runs with the correct RequestContext · eeb59fc3
      Andrii Grynenko authored
      Reviewed By: yfeldblum
      
      Differential Revision: D22604684
      
      fbshipit-source-id: 4dedb9c831d0a2137d16bbe0514e00a1c8f77f4a
      eeb59fc3