Skip to content
Snippets Groups Projects
  1. Mar 25, 2020
    • Nat Goodspeed's avatar
      DRTVWR-476: Defend against late ~LLWatchdogTimeout() calls. · ec208ddf
      Nat Goodspeed authored
      LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late
      as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has
      already called LLSingletonBase::deleteAll(), destroying the LLWatchdog
      LLSingleton instance.
      
      But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls
      stop(), and stop() tries to remove that instance from LLWatchdog, thus
      inadvertently resurrecting the deleted LLWatchdog. Which is pointless because
      the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance
      trying to remove itself.
      
      Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has
      already been deleted.
      ec208ddf
    • Nat Goodspeed's avatar
      7f1a2002
    • Nat Goodspeed's avatar
      DRTVWR-476: Try to extend stderr redirection to Windows as well. · 07134aae
      Nat Goodspeed authored
      Make the LLError::Settings LLSingleton duplicate the file handle for stderr
      (usually 2) on construction. Make its destructor restore the original target
      for that file handle. Provide a getDupStderr() method to obtain the duplicate
      file handle.
      
      Move Settings declaration up to the top of the file so other code can
      reference it.
      
      Make RecordToFile (the Recorder subclass engaged by LLError::logToFile()),
      instead of duplicating stderr's file handle itself, capture the duplicate
      stderr file handle from Settings to revert stderr redirection on destruction.
      
      Make RecordToStderr (the Recorder subclass engaged by LLError::logToStderr())
      use fdopen() to create an LLFILE* targeting the duplicate file handle from
      Settings. Write output to that instead of to stderr so logToStderr() continues
      to provide output for the user instead of duplicating each line into the log
      file.
      07134aae
    • Nat Goodspeed's avatar
      DRTVWR-476: Add diagnostic output to llviewerjoystick.cpp. · f80b2da5
      Nat Goodspeed authored
      Add ndof_dump_list() call, to enumerate available devices, when
      ndof_init_first() returns failure.
      
      Add "joystick" tags to existing LL_INFOS() (etc.) calls in
      llviewerjoystick.cpp to make it easier to enable and disable such log
      messages.
      
      Add a specialized operator<<() function to log the contents of an NDOF_Device
      struct. Add a couple LL_DEBUGS() calls for more visibility into library
      operations.
      f80b2da5
    • Nat Goodspeed's avatar
      DRTVWR-476: Try to log stderr output from classic-C libraries. · 7845f73c
      Nat Goodspeed authored
      Some of the libraries we use produce log output to stderr. Such output can be
      informative, but is invisible unless you launch the viewer from a console. In
      particular, it's invisible to anyone trying to diagnose a problem by reading
      someone else's SecondLife.log file.
      
      Make RecordToFile -- the Recorder subclass engaged by LLError::logToFile() --
      redirect STDERR_FILENO to the newly-opened log file so that any subsequent
      writes to stderr (or cerr, for that matter) will be captured in the log file.
      But first duplicate the original stderr file handle, and restore it when
      RecordToFile is destroyed. That way, output written to stderr during the final
      moments of application shutdown should still appear on (console) stderr.
      7845f73c
    • Nat Goodspeed's avatar
      DRTVWR-476: Add LLUniqueFile, adding RAII semantics to LLFILE*. · 9f446be7
      Nat Goodspeed authored
      LLUniqueFile wraps an LLFILE* in a move-only class that closes the wrapped
      LLFILE* on destruction. It provides conversion operators to permit idiomatic
      usage as an LLFILE* value.
      9f446be7
    • Nat Goodspeed's avatar
      DRTVWR-476: Use shared_ptr to manage lifespan of coprocedure queue. · cc6f1d61
      Nat Goodspeed authored
      Since the consuming coroutine LLCoprocedurePool::coprocedureInvokerCoro() has
      been observed to outlive the LLCoprocedurePool instance that owns the
      CoprocQueue_t, closing that queue isn't enough to keep the coroutine from
      crashing at shutdown: accessing a deleted CoprocQueue_t is fatal whether or
      not it's been closed.
      
      Make LLCoprocedurePool store a shared_ptr to a heap CoprocQueue_t instance,
      and pass that shared_ptr by value to consuming coroutines. That way the
      CoprocQueue_t instance is guaranteed to live as long as the last interested
      party.
      cc6f1d61
    • Nat Goodspeed's avatar
      DRTVWR-476: Keep coroutine-local data on toplevel()'s stack frame. · 9008124d
      Nat Goodspeed authored
      Instead of heap-allocating a CoroData instance per coroutine, storing the
      pointer in a ptr_map and deleting it from the ptr_map once the
      fiber_specific_ptr for that coroutine is cleaned up -- just declare a stack
      instance on the top-level stack frame, the simplest C++ lifespan management.
      Derive CoroData from LLInstanceTracker to detect potential name collisions and
      to enumerate instances.
      
      Continue registering each coroutine's CoroData instance in our
      fiber_specific_ptr, but use a no-op deleter function.
      
      Make ~LLCoros() directly pump the fiber scheduler a few times, instead of
      having a special "LLApp" listener.
      9008124d
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      DRTVWR-476: Pump coroutines a few more times when we start quitting. · cbf146f2
      Nat Goodspeed authored
      By the time "LLApp" listeners are notified that the app is quitting, the
      mainloop is no longer running. Even though those listeners do things like
      close work queues and inject exceptions into pending promises, any coroutines
      waiting on those resources must regain control before they can notice and shut
      down properly. Add a final "LLApp" listener that resumes ready coroutines a
      few more times.
      
      Make sure every other "LLApp" listener is positioned before that new one.
      cbf146f2
    • Nat Goodspeed's avatar
      DRTVWR-476: Don't name the caught exception · 7541e784
      Nat Goodspeed authored
      unless we're going to reference it.
      7541e784
    • Nat Goodspeed's avatar
      DRTVWR-476: Terminate long-lived coroutines to avoid shutdown crash. · 1345a02b
      Nat Goodspeed authored
      Add LLCoros::TempStatus instances around known suspension points so
      printActiveCoroutines() can report what each suspended coroutine is waiting
      for.
      
      Similarly, sprinkle checkStop() calls at known suspension points.
      
      Make LLApp::setStatus() post an event to a new LLEventPump "LLApp" with a
      string corresponding to the status value being set, but only until
      ~LLEventPumps() -- since setStatus() also gets called very late in the
      application's lifetime.
      
      Make postAndSuspendSetup() (used by postAndSuspend(), suspendUntilEventOn(),
      postAndSuspendWithTimeout(), suspendUntilEventOnWithTimeout()) add a listener
      on the new "LLApp" LLEventPump that pushes the new LLCoros::Stopping exception
      to the coroutine waiting on the LLCoros::Promise. Make it return the new
      LLBoundListener along with the previous one.
      
      Accordingly, make postAndSuspend() and postAndSuspendWithTimeout() store the
      new LLBoundListener returned by postAndSuspendSetup() in a LLTempBoundListener
      (as with the previous one) so it will automatically disconnect once the wait
      is over.
      
      Make each LLCoprocedurePool instance listen on "LLApp" with a listener that
      closes the queue on which new work items are dispatched. Closing the queue
      causes the waiting dispatch coroutine to terminate. Store the connection in an
      LLTempBoundListener on the LLCoprocedurePool so it will disconnect
      automatically on destruction.
      
      Refactor the loop in coprocedureInvokerCoro() to instantiate TempStatus around
      the suspending call.
      
      Change a couple spammy LL_INFOS() calls to LL_DEBUGS(). Give all logging calls
      in that module a "CoProcMgr" tag to make it straightforward to re-enable the
      LL_DEBUGS() calls as desired.
      1345a02b
    • Nat Goodspeed's avatar
      DRTVWR-476: Infrastructure to help manage long-lived coroutines. · 28a54c2f
      Nat Goodspeed authored
      Introduce LLCoros::Stop exception, with subclasses Stopping, Stopped and
      Shutdown. Add LLCoros::checkStop(), intended to be called periodically by any
      coroutine with nontrivial lifespan. It checks the LLApp status and, unless
      isRunning(), throws one of these new exceptions.
      
      Make LLCoros::toplevel() catch Stop specially and log forcible coroutine
      termination.
      
      Now that LLApp status matters even in a test program, introduce a trivial
      LLTestApp subclass whose sole function is to make isRunning() true.
      (LLApp::setStatus() is protected: only a subclass can call it.) Add LLTestApp
      instances to lleventcoro_test.cpp and lllogin_test.cpp.
      
      Make LLCoros::toplevel() accept parameters by value rather than by const
      reference so we can continue using them even after context switches.
      
      Make private LLCoros::get_CoroData() static. Given that we've observed some
      coroutines living past LLCoros destruction, making the caller call
      LLCoros::instance() is more dangerous than encapsulating it within a static
      method -- since the encapsulated call can check LLCoros::wasDeleted() first
      and do something reasonable instead. This also eliminates the need for both a
      const and non-const overload.
      
      Defend LLCoros::delete_CoroData() (cleanup function for fiber_specific_ptr for
      CoroData, implicitly called after coroutine termination) against calls after
      ~LLCoros().
      
      Add a status string to coroutine-local data, with LLCoro::setStatus(),
      getStatus() and RAII class TempStatus.
      
      Add an optional 'when' string argument to LLCoros::printActiveCoroutines().
      Make ~LLCoros() print the coroutines still active at destruction.
      28a54c2f
    • Nat Goodspeed's avatar
      DRTVWR-476: Mention LLApp::stepFrame() in LLAppViewer::idle() · 253e3600
      Nat Goodspeed authored
      which performs "by hand" the same sequence of calls found in stepFrame().
      
      Why not simply call stepFrame()? Hysterical reasons?
      253e3600
    • Nat Goodspeed's avatar
      DRTVWR-476: Make ~LLEventPumps() call reset() on its way out. · aea1e469
      Nat Goodspeed authored
      ~LLEventPumps() deletes every LLEventPump instance it created itself. However,
      many classes themselves contain LLEventPump subclass instances. These are
      registered with LLEventPumps without it managing their lifespan.
      
      But LLEventPump::reset() frees the LLStandardSignal aka
      boost::signals2::signal instance owned by the LLEventPump, perforce
      disconnecting all current listeners and disabling the LLEventPump. Even though
      the instance still exists, if someone subsequently calls post(), nothing will
      happen -- which is better than control trying to reach a method of a deleted
      object.
      aea1e469
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      aaae4478
    • Nat Goodspeed's avatar
      DRTVWR-476: Add LLEventTimer::run_every(), run_at(), run_after(). · 2f866c9d
      Nat Goodspeed authored
      Also add corresponding LLEventTimeout::post_every(), post_at(), post_after()
      methods.
      2f866c9d
    • Nat Goodspeed's avatar
      DRTVWR-476: Eliminate static LLEventPump factory maps. · 95a218fc
      Nat Goodspeed authored
      Having a map from std::string to a factory function returning LLEventPump* is
      a cool idea, especially since you could statically populate such a map with
      string literals and little lambdas.
      
      Unfortunately, static initialization of any data is a bad idea when control
      can reach consuming code before that module's static data are constructed.
      
      Since LLEventPumps is already an LLSingleton, it's simple enough to make its
      map non-static and initialize it in the constructor.
      
      But another recent static factory-function map was introduced in
      llleaplistener.cpp to support the LLLeapListener::newpump() operation. That
      involves no LLSingletons.
      
      Introduce LLEventPumps::make(name, tweak, type) to instantiate an LLEventPump
      subclass of the specified type with specified (name, tweak) parameters.
      Instances returned by make() are owned by LLEventPumps, as with obtain().
      Introduce LLEventPumps::BadType exception for when the type string isn't
      recognized.
      
      LLEventPumps::obtain() can then simply call make() when the specified instance
      name doesn't already exist. The configuration data used internally by obtain()
      becomes { string instance name, string subclass name }. Although this too is
      currently initialized in the LLEventPumps constructor, migrating it to a
      configuration file would now be far more straightforward than before.
      
      LLLeapListener::newpump(), too, can call LLEventPumps::make() with the
      caller-specified type string. This eliminates that static factory map.
      newpump() must catch BadType and report the error back to its invoker.
      
      Given that the LLEventPump subclass instances returned by make() are owned by
      LLEventPumps rather than LLLeapListener, there is no further need for the
      LLLeapListener::mEventPumps ptr_map, which was used only to manage lifetime.
      Also remove LLLeapListener's "killpump" operation since LLEventPumps provides
      no corresponding functionality.
      95a218fc
    • Nat Goodspeed's avatar
      DRTVWR-476: Seems gcc 4.8 forbids brace-init of reference vars. · 3ec92b0e
      Nat Goodspeed authored
      Although this is legal, apparently there was a bug in the C++11 standard (to
      which gcc 4.8 conforms) that was subsequently fixed in the standard (and thus
      in gcc 4.9). Thanks Henri Beauchamp.
      3ec92b0e
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      DRTVWR-476: Kill LLEventQueue, per-frame LLEventPump::flush() calls. · 79a3e391
      Nat Goodspeed authored
      No one uses LLEventQueue to defer posted events until the next mainloop tick
      -- and with LLCoros moving to Boost.Fiber, cross-coroutine event posting works
      that way anyway, making LLEventQueue pretty unnecessary.
      
      The static RegisterFlush instance in llevents.cpp was used to call
      LLEventPumps::flush() once per mainloop tick, which in turn called flush() on
      every registered LLEventPump. But the only reason for that mechanism was to
      support LLEventQueue. In fact, when LLEventMailDrop overrode its flush()
      method for something quite different, it was startling to find that the new
      flush() override was being called once per frame -- which caused at least one
      fairly mysterious bug. Remove RegisterFlush. Both LLEventPumps::flush() and
      LLEventPump::flush() remain for now, though intended usage is unclear.
      
      Eliminating LLEventQueue means we must at least repurpose
      LLEventPumps::mQueueNames, a map intended to make LLEventPumps::obtain()
      instantiate an LLEventQueue rather than the default LLEventPump. Replace it
      with mFactories, a map from desired instance name to a callable returning
      LLEventPump*. New map initialization syntax plus lambda support allows us to
      populate that map at compile time with little lambdas returning the correct
      subclass instance.
      
      Similarly, LLLeapListener::newpump() used to check the ["type"] entry in the
      LLSD request specifically for "LLEventQueue". Introduce another such map in
      llleaplistener.cpp for potential future extensibility.
      
      Eliminate the LLEventQueue-specific test.
      79a3e391
    • Nat Goodspeed's avatar
      DRTVWR-476: Introduce LLEventMailDrop::discard() (instead of flush()). · 6805e82a
      Nat Goodspeed authored
      Overriding virtual LLEventPump::flush() for the semantic of discarding
      LLEventMailDrop's queued events turns out not to be such a great idea, because
      LLEventPumps::flush(), which calls every registered LLEventPump's flush()
      method, is called every mainloop tick. The first time we hit a use case in
      which we expected LLEventMailDrop to hold queued events across a mainloop tick,
      we were baffled that they were never delivered.
      
      Moving that logic to a separate method specific to LLEventMailDrop resolves
      that problem. Naming it discard() clarifies its intended functionality.
      6805e82a
    • Nat Goodspeed's avatar
      DRTVWR-476: Directly reference LLVivoxVoiceClient::mVivoxPump. · 4d65539d
      Nat Goodspeed authored
      The LLEventMailDrop used to communicate with the Vivox coroutine is a member
      of LLVivoxVoiceClient. We don't need to keep looking it up by its string name
      in LLEventPumps.
      4d65539d
    • Nat Goodspeed's avatar
      DRTVWR-476: Add LLEventLogProxy, LLEventLogProxyFor<T>. · 53aeea4d
      Nat Goodspeed authored
      LLEventLogProxy can be introduced to serve as a logging proxy for an existing
      LLEventPump subclass instance. Access through the LLEventLogProxy will be
      logged; access directly to the underlying LLEventPump will not.
      
      LLEventLogProxyFor<LLEventPumpSubclass> functions as a drop-in replacement for
      the original LLEventPumpSubclass instance. It internally instantiates
      LLEventPumpSubclass and serves as a proxy for that instance.
      
      Add unit tests for LLEventMailDrop and LLEventLogProxyFor<LLEventMailDrop>,
      both "plain" (events only) and via lleventcoro.h synchronization.
      53aeea4d
    • Nat Goodspeed's avatar
      DRTVWR-476: Validate LLEventPumpOrPumpName replyPump · 6945755e
      Nat Goodspeed authored
      passed to postAndSuspendsetup().
      
      The requestPump is optional, and the function varies its behavior depending on
      whether that parameter is empty or meaningful. But it unconditionally uses the
      replyPump. Passing an empty LLEventPumpOrPumpName caused mysterious crashes.
      Add llassert_always_msg() to make the coding error explicit in such a case.
      
      Also streamline access to meaningful requestPump and replyPump by temporarily
      caching the bound LLEventPump reference.
      6945755e
    • Nat Goodspeed's avatar
      DRTVWR-476: Remove special case for listen(boost::bind(weak_ptr)). · afaad3ce
      Nat Goodspeed authored
      LLEventDetail::visit_and_connect() promised special treatment for the
      specific case when an LLEventPump::listen() listener was composed of (possibly
      nested) boost::bind() objects storing boost::weak_ptr values -- specifically
      boost::bind() rather than std::bind or lambdas, specifically boost::weak_ptr
      rather than std::weak_ptr.
      
      Outside of self-tests, it does not appear that anyone actually uses that
      support.
      
      There is good reason not to: it's a silent side effect of a complicated
      compile-time inspection that could be silently derailed by use of std::bind()
      or a lambda or a std::weak_ptr. Can you be sure you've engaged that promise?
      How?
      
      A more robust guarantee can be achieved by storing an LLTempBoundConnection in
      the transient object itself. When the object is destroyed, the listener is
      disconnected. Normal C++ rules around object destruction guarantee it. This
      idiom is widely used.
      
      There are a couple good reasons to remove the visit_and_connect() machinery:
      
      * boost::bind() and boost::weak_ptr do not constitute the wave of the future.
        Preferring those constructs to lambdas and std::weak_ptr penalizes new code,
        whether by silently failing or by discouraging use of modern idioms.
      * The visit_and_connect() machinery was always complicated, and apparently
        never very robust. Most of its promised features have been commented out
        over the years. Making the code base simpler, clearer and more maintainable
        is always a useful effect.
      
      LLEventDetail::visit_and_connect() was also used by the four
      LLNotificationChannelBase::connectMumble() methods. Streamline those as well.
      
      Of course, remove related test code.
      afaad3ce
    • Nat Goodspeed's avatar
      DRTVWR-476: Remove llwrap(), LLListenerWrapper[Base] and support. · 18e2b9ca
      Nat Goodspeed authored
      The only usage of any of this was in test code.
      18e2b9ca
    • Nat Goodspeed's avatar
      0cde6669
    • Nat Goodspeed's avatar
      DRTVWR-476: Add llsd::array() and llsd::map() variadic functions. · 52d15b64
      Nat Goodspeed authored
      llsd::array(), as one might suspect, takes an arbitrary number of arguments of
      arbitrary convertible types and returns an LLSD::Array constructed from those
      elements. This supercedes the older LLSDArray class.
      
      llsd::map() takes an even number of arguments paired as (LLSD::String,
      arbitrary convertible type) and returns an LLSD::Map constructed from those
      (key, value) pairs. This supercedes the older LLSDMap class.
      
      These two functions not only have a simpler API -- arbitrary function
      arguments rather than an (arg list)(arg list) sequence -- but also
      specifically return a final LLSD object, rather than needing conversion to
      LLSD from the LLSDArray or LLSDMap object.
      
      Also support LLSD == LLSD and LLSD != LLSD comparisons, using llsd_equals()
      with default exact-float-equality semantics.
      52d15b64
    • Nat Goodspeed's avatar
      ce2b56b2
    • Nat Goodspeed's avatar
      DRTVWR-476: Make test program --debug switch work like LOGTEST=DEBUG. · 6b70493d
      Nat Goodspeed authored
      The comments within indra/test/test.cpp promise that --debug is, in fact, like
      LOGTEST=DEBUG. Until now, that was a lie. LOGTEST=level displayed log output
      on stderr as well as in testprogram.log, while --debug did not.
      
      Add LLError::logToStderr() function, and make initForApplication() (i.e.
      commonInit()) call that instead of instantiating RecordToStderr inline. Also
      call it when test.cpp recognizes --debug switch.
      
      Remove the mFileRecorder, mFixedBufferRecorder and mFileRecorderFileName
      members from SettingsConfig. That tactic doesn't scale.
      
      Instead, add findRecorder<RECORDER>() and removeRecorder<RECORDER>() template
      functions to locate (or remove) a RecorderPtr to an object of the specified
      subclass. Both are based on an underlying findRecorderPos<RECORDER>() template
      function. Since we never expect to manage more than a handful of RecorderPtrs,
      and since access to the deleted members is very much application setup rather
      than any kind of ongoing access, a search loop suffices.
      
      logToFile() uses removeRecorder<RecordToFile>() rather than removing
      mFileRecorder (the only use of mFileRecorder).
      
      logToFixedBuffer() uses removeRecorder<RecordToFixedBuffer>() rather than
      removing mFixedBufferRecorder (the only use of mFixedBufferRecorder).
      
      Make RecordToFile store the filename with which it was instantiated. Add a
      getFilename() method to retrieve it. logFileName() is now based on
      findRecorder<RecordToFile>() instead of mFileRecorderFileName (the only use of
      mFileRecorderFileName).
      
      Make RecordToStderr::mUseANSI a simple bool rather than a three-state enum,
      and set it immediately on construction. Apparently the reason it was set
      lazily was because it consults its own checkANSI() method, and of course
      'this' doesn't acquire the leaf class type until the constructor has completed
      successfully. But since nothing in checkANSI() depends on anything else in
      RecordToStderr, making it static solves that problem.
      6b70493d
    • Nat Goodspeed's avatar
      DRTVWR-476: Fix overflow case in llcoro::postAndSuspend(). · e4d6383c
      Nat Goodspeed authored
      Actually the fix is in postAndSuspendSetup(), which affects postAndSuspend(),
      postAndSuspendWithTimeout(), suspendUntilEventOnWithTimeout() and
      suspendUntilEventOn().
      
      By "overflow case" we mean the special circumstance in which:
      
      * the LLEventPump in question is an LLEventMailDrop, meaning its listeners
        eventually expect to see every post()ed value
      * one of the listeners is supposed to consume those values (has called
        LLCoros::set_consuming(true))
      * post() is called more than once before that listener is resumed.
      
      The magic of postAndSuspend() (et al.) is a temporary LLCoros::Promise. The
      waiting coroutine calls get() on the corresponding Future, causing it to
      suspend (as promised) until the Promise is fulfilled.
      
      With the Boost.Fiber implementation of coroutines, fulfilling the Promise
      doesn't immediately resume the suspended coroutine -- it merely marks it ready
      to resume, next time the scheduler gets control.
      
      A second post() call before the suspended coroutine is resumed results in a
      second call to Promise::set_value(). But Promise is a one-shot entity. This
      results in a promise_already_satisfied exception. Because a second post() call
      during that time window is perfectly reasonable, we catch that exception and
      carry on.
      
      The tricky part is: when that exception is thrown, what should the listener
      return? Previously we were returning the listener's current consuming setting,
      just as when the set_value() call succeeds.
      
      But when the LLEventPump is an LLEventMailDrop, and the listener's consuming
      flag is true, that told LLEventMailDrop::post() that the value got through,
      and that it needn't bother to save it in its history queue. The net effect was
      to discard the value.
      
      Instead, return the listener's consuming flag only when Promise::set_value()
      succeeds. When it throws promise_already_satisfied, unconditionally return
      false. That directs LLEventMailDrop::post() to enqueue the undelivered value
      so that the *next* suspendUntilEventOn() call can pick it up.
      e4d6383c
    • Nat Goodspeed's avatar
      DRTVWR-476: Fix Windows line endings · 16b76837
      Nat Goodspeed authored
      16b76837
    • Nat Goodspeed's avatar
      54bc5ee9
    • Nat Goodspeed's avatar
      eb75b358
    • Nat Goodspeed's avatar
      DRTVWR-476: Update vlc-bin, jsoncpp, pcre, libndofdev, libhunspell, bugsplat,... · 6a3b0363
      Nat Goodspeed authored
      DRTVWR-476: Update vlc-bin, jsoncpp, pcre, libndofdev, libhunspell, bugsplat, fmodex, llca, jpeglib, libxml2, slvoice, glod, dullahan, glext, kdu, uriparser, glh_linear, tut, nghttp2, dictionaries, zlib, llphysicsextensions_source, openjpeg, nvapi, expat, viewer-manager, google_breakpad, libpng, ogg_vorbis, openssl, xmlrpc-epi, apr_suite, freetype, boost, colladadom, googlemock, curl, havok-source
      
      Update vlc-bin to codeticket version 531366.
      Update jsoncpp to codeticket version 531360.
      Update pcre to codeticket version 531373.
      Update libndofdev to codeticket version 531359.
      Update libhunspell to codeticket version 531369.
      Update bugsplat to codeticket version 531352.
      Update fmodex to codeticket version 531266.
      Update llca to codeticket version 531253.
      Update jpeglib to codeticket version 531361.
      Update libxml2 to codeticket version 531380.
      Update slvoice to codeticket version 531358.
      Update glod to codeticket version 531370.
      Update dullahan to codeticket version 531387.
      Update glext to codeticket version 531247.
      Update kdu to codeticket version 531363.
      Update uriparser to codeticket version 531367.
      Update glh_linear to codeticket version 531260.
      Update tut to codeticket version 531246.
      Update nghttp2 to codeticket version 531364.
      Update dictionaries to codeticket version 531288.
      Update zlib to codeticket version 531372.
      Update llphysicsextensions_source to codeticket version 531362.
      Update openjpeg to codeticket version 531368.
      Update nvapi to codeticket version 531376.
      Update expat to codeticket version 531365.
      Update viewer-manager to codeticket version 531239.
      Update google_breakpad to codeticket version 531388.
      Update libpng to codeticket version 531386.
      Update ogg_vorbis to codeticket version 531357.
      Update openssl to codeticket version 531379.
      Update xmlrpc-epi to codeticket version 531374.
      Update apr_suite to codeticket version 531375.
      Update freetype to codeticket version 531385.
      Update boost to codeticket version 531381.
      Update colladadom to codeticket version 531391.
      Update googlemock to codeticket version 531390.
      Update curl to codeticket version 531389.
      Update havok-source to codeticket version 531509.
      6a3b0363
    • Nat Goodspeed's avatar
      e33a747d
    • Nat Goodspeed's avatar
      DRTVWR-476: Re-enable an llcoproceduremanager_test case. · 6f879178
      Nat Goodspeed authored
      Use new Sync class to make the driving logic wait for the coprocedure to run.
      6f879178
    • Nat Goodspeed's avatar
      DRTVWR-476: Add Sync class to help with stepwise coroutine tests. · d7c2e4a7
      Nat Goodspeed authored
      Sync is specifically intended for test programs. It is based on an
      LLScalarCond<int>. The idea is that each of two coroutines can watch for the
      other to get a chance to run, indicated by incrementing the wrapped int and
      notifying the wrapped condition_variable. This is less hand-wavy than calling
      llcoro::suspend() and hoping that the other routine will have had a chance to
      run.
      
      Use Sync in lleventcoro_test.cpp.
      
      Also refactor lleventcoro_test.cpp so that instead of a collection of static
      data requiring a clear() call at start of each individual test function, the
      relevant data is all part of the test_data struct common to all test
      functions. Make the helper coroutine functions members of test_data too.
      
      Introduce llcoro::logname(), a convenience function to log the name of the
      currently executing coroutine or "main" if in the thread's main coroutine.
      d7c2e4a7
Loading