Skip to content
Snippets Groups Projects
  1. Nov 02, 2021
  2. Jun 07, 2021
  3. Apr 26, 2021
  4. Mar 09, 2021
  5. Mar 08, 2021
  6. Sep 17, 2020
  7. Mar 25, 2020
    • 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
  8. Jun 12, 2019
  9. Sep 07, 2018
  10. Sep 05, 2018
  11. Sep 04, 2018
  12. Aug 08, 2018
    • Nat Goodspeed's avatar
      Fix cmake -E copy of CrashReporter.nib. · 6ae2f142
      Nat Goodspeed authored
      indra/mac_crash_logger/CMakeLists.txt was using 'cmake -E copy_directory' to
      copy CrashReporter.nib -- which is actually a binary file. Apparently that
      works, until CMake 3.12.0, which produces an error. Use copy_if_different
      instead.
      6ae2f142
  13. Jun 30, 2016
    • Nat Goodspeed's avatar
      DRTVWR-418: Unify control flow through LLAppViewer across platforms. · 464a0df4
      Nat Goodspeed authored
      The LLApp API used to consist of init(), mainLoop(), cleanup() methods. This
      makes sense -- but on Mac that structure was being subverted. The method
      called mainLoop() was in fact being called once per frame. There was
      initialization code in the method, which (on Mac) needed to be skipped with an
      already-initialized bool. There was a 'while' loop which (on Mac) needed to be
      turned into an 'if' instead so the method would return after every frame.
      
      Rename LLApp::mainLoop() to frame(). Propagate through subclasses LLAppViewer
      and LLCrashLogger. Document the fact that frame() returns true to mean "done."
      (This was always the case, but had to be inferred from the code.)
      
      Rename the Mac Objective-C function mainLoop to oneFrame. Rename the C++ free
      function it calls from runMainLoop() to pumpMainLoop(). Add comments to
      llappdelegate-objc.mm explaining (inferred) control flow.
      
      Change the Linux viewer main() and the Windows viewer WINMAIN() from a single
      LLAppViewer::mainLoop() call to repeatedly call frame() until it returns true.
      
      Move initialization code from the top of LLAppViewer::frame() to the init()
      method, where it more properly belongs. Remove corresponding
      mMainLoopInitialized flag (and all references) from LLAppViewer.
      
      Remove 'while (! LLApp::isExiting())' (or on Mac, 'if (! LLApp::isExiting())')
      from LLAppViewer::frame() -- thus unindenting the whole body of the 'while'
      and causing many lines of apparent change. (Apologies to reviewers.)
      
      There are four LLApp states: APP_STATUS_RUNNING, APP_STATUS_QUITTING,
      APP_STATUS_STOPPED and APP_STATUS_ERROR. Change LLAppViewer::frame() return
      value from (isExiting()) (QUITTING or ERROR) to (! isRunning()). I do not know
      under what circumstances the state might transition to STOPPED during a
      frame() call, but I'm quite sure that if it does, we don't want to call
      frame() again. We only want a subsequent call if the state is RUNNING.
      
      Also rename mainLoop() method in LLCrashLogger subclasses
      LLCrashLoggerWindows, LLCrashLoggerMac, LLCrashLoggerLinux. Of course it's
      completely up to the frame() method whether to yield control; none of those in
      fact do. Honor protocol by returning true (frame() is done), even though each
      one's main() caller ignores the return value.
      
      In fact LLCrashLoggerWindows::mainLoop() wasn't using the return protocol
      correctly anyway, returning wParam or 0 or 1 -- possibly because the return
      protocol was never explicitly documented. It should always return true: "I'm
      done, don't call me again."
      464a0df4
  14. Apr 13, 2016
  15. Mar 08, 2016
  16. Nov 10, 2015
  17. Sep 16, 2015
  18. Jun 17, 2015
  19. Apr 30, 2015
  20. Nov 20, 2014
  21. Dec 03, 2013
  22. Aug 15, 2013
  23. Apr 30, 2013
  24. Mar 29, 2013
  25. Dec 13, 2012
  26. Dec 11, 2012
  27. Nov 30, 2012
  28. Nov 12, 2012
  29. Oct 10, 2012
  30. Oct 03, 2012
  31. Sep 21, 2012
  32. Oct 27, 2011
  33. Jul 12, 2011
  34. Oct 13, 2010
  35. Sep 21, 2010
Loading