Skip to content
Snippets Groups Projects
  1. May 05, 2023
  2. May 03, 2023
  3. Apr 02, 2023
  4. Sep 21, 2022
  5. Sep 17, 2022
  6. May 06, 2022
  7. Apr 30, 2022
  8. Apr 16, 2022
  9. Apr 13, 2022
  10. Apr 06, 2022
  11. Feb 11, 2022
  12. Aug 08, 2021
  13. Nov 09, 2020
  14. Aug 07, 2020
  15. Jul 22, 2020
  16. Jul 21, 2020
  17. Mar 25, 2020
    • Anchor's avatar
      [DRTVWR-476] - fix linking · b5bb0794
      Anchor authored
      b5bb0794
    • Anchor's avatar
      [DRTVWR-476] - test adding at beginiing of list · 761d9aa3
      Anchor authored
      761d9aa3
    • Anchor's avatar
    • Nat Goodspeed's avatar
      SL-793: Use Boost.Fiber instead of the "dcoroutine" library. · 66981fab
      Nat Goodspeed authored
      Longtime fans will remember that the "dcoroutine" library is a Google Summer
      of Code project by Giovanni P. Deretta. He originally called it
      "Boost.Coroutine," and we originally added it to our 3p-boost autobuild
      package as such. But when the official Boost.Coroutine library came along
      (with a very different API), and we still needed the API of the GSoC project,
      we renamed the unofficial one "dcoroutine" to allow coexistence.
      
      The "dcoroutine" library had an internal low-level API more or less analogous
      to Boost.Context. We later introduced an implementation of that internal API
      based on Boost.Context, a step towards eliminating the GSoC code in favor of
      official, supported Boost code.
      
      However, recent versions of Boost.Context no longer support the API on which
      we built the shim for "dcoroutine." We started down the path of reimplementing
      that shim using the current Boost.Context API -- then realized that it's time
      to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
      which we've been itching to do for literally years now.
      
      Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
      lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
      the differences between "dcoroutine" and Boost.Fiber.
      
      The one feature Boost.Fiber does not provide is the ability to forcibly
      terminate some other fiber. Accordingly, disable LLCoros::kill() and
      LLCoprocedureManager::shutdown(). The only known shutdown() call was in
      LLCoprocedurePool's destructor.
      
      We also took the opportunity to remove postAndSuspend2() and its associated
      machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
      LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
      when the Responder pattern was king, and we assumed we'd want to listen on one
      LLEventPump with the success handler and on another with the error handler. We
      have never actually used that in practice. Remove associated tests, of course.
      
      There is one other semantic difference that necessitates patching a number of
      tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
      coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
      ready to resume next time the scheduler gets around to it. To observe the test
      side effects, we've inserted a number of llcoro::suspend() calls -- also in
      the main loop.
      
      For a long time we retained a single unit test exercising the raw "dcoroutine"
      API. Remove that.
      
      Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
      hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
      that, remove the hack.
      
      In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
      tracking in place of llcoro::get_id().
      
      In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
      don't actually use the Boost.Coroutine for anything (though there exist
      plausible use cases).
      66981fab
  18. Mar 02, 2019
  19. Sep 07, 2018
  20. Sep 05, 2018
  21. May 08, 2017
    • Nat Goodspeed's avatar
      DRTVWR-418: Fix -std=c++11 llinstancetracker_test crash. · 322c4c6b
      Nat Goodspeed authored
      LLInstanceTracker<T> performs validation in ~LLInstanceTracker(). Normally
      validation failure logs an error and terminates the program, which is fine. In
      the test executable, though, we want validation failure to throw an exception
      instead so we can catch it and continue testing other failure conditions. But
      since destructors in C++11 are implicitly noexcept(true), that exception never
      made it out of ~LLInstanceTracker(): it crashed the test program instead.
      Declaring ~LLInstanceTracker() noexcept(false) solves that, allowing the test
      program to catch the exception and continue.
      
      However, if we unconditionally declare that, then every destructor anywhere in
      the inheritance hierarchy for any LLInstanceTracker subclass must also be
      noexcept(false)! That's way too pervasive, especially for functionality we
      only need (or want) in a specific test executable.
      
      Instead, make the CMake macros LL_ADD_PROJECT_UNIT_TESTS() and
      LL_ADD_INTEGRATION_TEST() -- with which we define all viewer build-time tests
      -- define two new command-line macros: LL_TEST=testname and LL_TEST_testname.
      That way, preprocessor logic in a header file can detect whether it's being
      compiled for production code or for a test executable.
      
      (While at it, encapsulate in a new GET_OPT_SOURCE_FILE_PROPERTY() CMake macro
      an ugly repetitive pattern. The builtin GET_SOURCE_FILE_PROPERTY() sets the
      target variable to "NOTFOUND" -- rather than an empty string -- if the
      specified property wasn't set. Every call to GET_SOURCE_FILE_PROPERTY() in
      LL_ADD_PROJECT_UNIT_TESTS() was followed by a test for NOTFOUND and an
      assignment to "". Wrap all that in a macro whose 'unset' value is "".)
      
      Now llinstancetracker.h can detect when we're building the LLInstanceTracker
      unit test executable, and *only then* declare ~LLInstanceTracker() as
      noexcept(false). We #define LLINSTANCETRACKER_DTOR_NOEXCEPT to expand either
      empty or noexcept(false), also detecting clang in C++11 mode. (It all works
      fine without noexcept(false) until we turn on C++11 mode.)
      
      We also use that macro for the StatBase class in lltrace.h. Turns out some of
      the infrastructure headers required for tests in general, including the
      LLInstanceTracker test, use LLInstanceTracker. Fortunately that appears to be
      the only other class we must annotate this way for the LLInstanceTracker tests.
      322c4c6b
  22. Dec 20, 2016
  23. Aug 17, 2015
  24. Aug 15, 2015
  25. Aug 14, 2015
  26. Oct 21, 2014
  27. Oct 13, 2014
  28. Mar 19, 2014
  29. Jan 09, 2014
  30. Mar 27, 2013
Loading