Fix up documentation and CHANGES.md

Author: timoore

CHANGES.md

@@ -1,5 +1,11 @@
 # Change Log
 
+### ? - ?
+
+##### Breaking Changes :mega:
+
+- `Tileset::updateViewGroupOffline`, `Tileset::updateViewGroup`, and `Tileset::loadTiles` no longer call `AsyncSystem::dispatchMainThreadTasks`. Client applications must call that function themselves from their main thread.
+
 ### v0.58.0 - 2026-03-02
 
 ##### Fixes :wrench:

Cesium3DTilesSelection/include/Cesium3DTilesSelection/Tileset.h

@@ -434,10 +434,6 @@ class CESIUM3DTILESSELECTION_API Tileset final {
    * In order to minimize tile load latency, this method should be called
    * frequently, such as once per render frame. It will return quickly when
    * there is no work to do.
-   *
-   * This method also calls
-   * {@link CesiumAsync::AsyncSystem::dispatchMainThreadTasks} on the tileset's
-   * {@link getAsyncSystem}, but not for long!
    */
   void loadTiles();
 

doc/topics/async-system.md

@@ -56,7 +56,7 @@ In practice, though, we almost never call `wait` or `waitInMainThread`. After al
 
 A continuation function is a callback - usually a lambda - that is invoked when the `Future` resolves. The name comes from the idea that the execution "continues" with that function after the async operation. Continuations are registered with the `then...` methods on the `Future`. Different `then` functions are used to control _in what thread_ the callback is invoked:
 
-* [thenInMainThread](@ref CesiumAsync::Future::thenInMainThread): The continuation function is invoked in the "main" thread. Many applications have a clear idea of which thread they consider the main one, but in Cesium Native, "main thread" very specifically means the thread that called `waitInMainThread` or [dispatchMainThreadTasks](@ref CesiumAsync::AsyncSystem::dispatchMainThreadTasks) on the `AsyncSystem`. This need not be the same as the thread your application considers to be the main one.
+* [thenInMainThread](@ref CesiumAsync::Future::thenInMainThread): The continuation function is invoked in the "main" thread. Many applications have a clear idea of which thread they consider the main one, but in Cesium Native, "main thread" very specifically means the thread that called `waitInMainThread` or [dispatchMainThreadTasks](@ref CesiumAsync::AsyncSystem::dispatchMainThreadTasks) on the `AsyncSystem`. This need not be the same as the thread your application considers to be the main one; however, your application must call `dispatchMainThreadTasks` periodically from a unique thread in order for main thread continuation functions to run at all.
 * [thenInWorkerThread](@ref CesiumAsync::Future::thenInWorkerThread): The continuation function is invoked in a background worker thread by calling [startTask](@ref CesiumAsync::ITaskProcessor::startTask) on the `ITaskProcessor` instance with which the `AsyncSystem` was constructed.
 * [thenInThreadPool](@ref CesiumAsync::Future::thenInThreadPool): The continuation function is invoked in a specified [ThreadPool](@ref CesiumAsync::ThreadPool). This is most commonly used with a `ThreadPool` containing just a single thread, in order to delegate certain tasks (such as database access) to a dedicated thread. In other cases, `thenInWorkerThread` is probably a better choice.
 * [thenImmediately](@ref CesiumAsync::Future::thenImmediately): The continuation function is invoked immediately in whatever thread happened to resolve the `Future`. This is only appropriate for work that completes very quickly and is safe to run in any thread.