Waiting is not a runtime — Parallax Sketchbook

SKETCHBOOK / 05 The Living Gallery · 2-week chapter

Page 1 of 6: A future describes a result state

Futures / launch policy

A future describes a result state

A future can represent a result or an exception that becomes available later. Unlike manually sharing result flags, it packages readiness and exception delivery in a shared state; it does not specify your queue or resource budget. Calling get may wait and then consumes the future's result. Readiness and cancellation are separate contracts: a timed wait returning not-ready does not stop the operation.

std::async without an explicit policy may choose deferred execution. With launch::async it launches as specified, but a loop that creates one async operation per asset is not a bounded executor. Use the batch reference for admission control; use a single future example to understand result ownership.

A future associated with std::async can also block during the relevant shared-state release, including destruction in common last-owner cases. Discarding a temporary future is not a reliable fire-and-forget pattern. The exact call and launch policy belong in your lifetime review.

LOOK CLOSER

#include <cstdint>
#include <future>
#include <vector>

std::uint64_t one_owned_future() {
    auto ready = std::async(std::launch::async,
        [samples = std::vector<std::uint32_t>{1, 2, 3}] {
            std::uint64_t sum = 0;
            for (auto value : samples) sum += value;
            return sum;
        }); // Ordinary lambda, not a coroutine.
    return ready.get(); // Waits; exceptions propagate to the caller.
}

One bounded teaching operation, not a thread-pool implementation. The caller owns its exception boundary.

From the page to your own work

Your studio assignment.

Run and explain a bounded Asio coroutine integration that preserves explicit ownership and completion.

A finish line you can see

A runnable timer success/cancel/failure trace, a frame-lifetime check, and a CP.51–53 review.

Use an explicit async launch policy in the isolated future experiment.
Explain exception delivery and potential blocking release.
Identify closure, lock, reference, and awaitable lifetime hazards.
Observe every Asio completion and drain the context before releasing borrowed callback state.

Keep the evidence in your weekly notebook ↗

Explain it like an engineer

Try answering aloud before opening the review notes. Use your own implementation as evidence.

What additional information do you need before approving a co_await asset loader?

Task/frame ownership, start policy, resumption context, and cancellation semantics.
Awaitable operation and buffer lifetimes.
A completion boundary before shutdown or resource release.

These prompts support practice; they are not an automatic assessment of your work.

A tip for this exercise

Compare the future experiment with the Asio timer checkpoint. Mark which call waits, which operation suspends, and who keeps the input and completion state alive until the runtime drains.

Hints, when you need them.

Try a first step, then reveal as much help as you need. Each hint gets a little more specific.

1Hint 1 · Find a starting point

Separate three questions: whether a result is ready, whether stop was requested, and whether all work has finished. A timed wait answers only the readiness question.

2Hint 2 · Choose an approach

For the future, trace the value or exception to get. For the named Asio coroutine, follow its value parameters into the frame, the posted cancellation handler, and the final completion callback.

3Hint 3 · Check your reasoning

Run the three Asio scenarios. Cancellation must record started, other handler, aborted wait, then completion; the weak payload probe expires after run drains. Explain why neither a captured coroutine lambda nor io_context::stop is needed.

A small creative variation ↗

Rewrite a conceptual reference-taking coroutine signature into an owned-value design, then list the lifetimes that still need review.

Optional. Save it for later if this chapter already feels full.

Coming back after a break? ↩

Run prism-coroutines unchanged; draw the timer, frame, payload, cancellation signal, and completion callback lifetimes.

Books & principles behind this study +

Original Parallax explanations and assignments, with these works for further reading.

YOUR MARGIN NOTES

Leave yourself a good question.

What changed your mind? What would you try next?

Notes for Waiting is not a runtime

Notes are private to this browser and saved as you write.

A CHECKPOINT, NOT A SCORE

Can you explain the idea and try the exercise yourself?

Completion records your own assessment. It does not compile or test your C++.

Companion source 14 files