Assets have revisions — Parallax Sketchbook

SKETCHBOOK / 04 The Living Gallery · 2-week chapter

Page 1 of 4: Separate readiness from identity

Assets / state machines

Separate readiness from identity

A gallery asset can be absent, preparing, ready, or failed, but those states are not enough to identify which request produced it. Give each requested revision a generation value and retain the currently published owner while a replacement is prepared.

An old job may finish after a newer request. It can be a perfectly successful computation and still be irrelevant to the current asset. Cancellation can reduce wasted work, but a generation check is still needed at publication because completion and stop requests can race.

Keep asset identity and generation as values, not pointers into a mutable map entry. If handles can be recycled, include a policy that prevents an old handle from naming a different asset. For a bounded first gallery, a monotonic checked generation and a stable asset identifier are enough.

TRY IT IN YOUR STUDIO

Draw request A, request B, completion B, completion A. Mark which completion may replace the published asset and why.

From the page to your own work

Your studio assignment.

Give the Living Gallery a small generation-aware asset preparation state machine.

A finish line you can see

An original state diagram, a stale-completion regression, and a failure-preserves-current test.

Keep identity separate from readiness state.
Check generation at publication even when cancellation exists.
Bound retained and queued assets.
Define generation exhaustion and borrowed-entry lifetime.

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.

Why does cancelling an old request not remove the need for revision checks?

The request may already have finished or may finish before observing stop.
Cancellation does not undo a produced value.
Publication must compare the identity of the current intent.

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

A tip for this exercise

Write the completion order before building the state machine. Keep the requested generation and the currently published owner separate, so a failed replacement can be reported while the last valid asset stays available.

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

A ready result can belong to an obsolete request. Add identity information to your state sketch and locate the exact publication decision where it must be checked.

2Hint 2 · Choose an approach

Prepare a complete replacement owner before swapping it into the published state. Require success and the current generation, then define duplicate-completion handling, retained-owner bounds, and generation exhaustion.

3Hint 3 · Check your reasoning

Request A, request B, finish B, then finish A: B should remain published. Follow with a failed current replacement and verify the same B owner survives while the new failure is recorded separately.

A small creative variation ↗

Add a deliberately reordered completion sequence to your tests without using real file timing.

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

Coming back after a break? ↩

Reduce the model to one asset and two generation numbers; test only accepts() first.

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 Assets have revisions

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