My browser-based editor splits work across uneven machines to render long exports. It divides the frames into chunks and hands them, through a relay, to volunteers who render in their own browsers. Some have fast graphics cards; some are on a laptop or a phone. A relay keeps track of who has which chunk. If a volunteer's browser goes quiet for too long, its claim lapses and the chunk is handed to someone else.
That is a standard pattern, and it has standard bugs.
Only the current claimant may finish
Picture a slow worker that takes a chunk, stalls, and lets its claim lapse. The chunk goes to a faster worker. Then the slow worker wakes up and reports the chunk as done, or asks for it to be reopened. The relay accepted both. A chunk could be marked complete by a worker that no longer owned it, while its real owner was still working, or reopened under the owner's feet.
Completing a chunk now checks that the reporting worker holds the chunk's current claim. Anyone else gets a not-claimant error. It is the same lesson as check-then-set races in WordPress: whoever finishes a piece of shared work must prove they still own it.
Chunk zero was not a number
Chunks have IDs like c0, c1 and so on. A loose parse treated c0 as "no number", fell back to the next free index, and wrote chunk zero's results over another segment. The ID is now parsed strictly, and a missing, malformed or out-of-range ID is rejected, with tests. Zero is a valid answer, and code that treats it as false will find a way to prove it.
Make the bookkeeping cheap
Claiming, counting and reopening chunks used to scan lists. With thousands of frames that adds up. The relay now keeps a queue of open chunk indices, a log of claims in claim order for reopening lapsed ones, a map of chunks in flight and running counters. Every operation is constant time on average, and completion reads the index straight from the ID.
Splitting work across uneven machines: plan big chunks first
Fixed-size chunks are fair to identical machines and unfair to everything else. A slow worker that picks up the last fixed chunk holds up the whole job.
Jobs can now ask for guided scheduling. Chunks are planned largest first, each sized at the remaining frames divided by twice the number of workers, within a minimum and a maximum. Early chunks are big, so per-claim overhead is small. Late chunks are small, so no single slow worker can hold the end hostage.
Duplicate the tail
Once nothing is left to hand out and only a few chunks are outstanding, an idle worker is given a duplicate of the oldest outstanding chunk. Whichever copy finishes first wins. The other report is acknowledged with zero frames, so nothing is counted twice. Jobs can switch this off.
| Simulated mixed fleet (frames per second) | Fixed chunks | Guided with duplicate tail |
|---|---|---|
| 30, 30, 12, 2 | 133.2 s | 102.4 s |
| 24, 24, 24, 1 | 150.0 s | 103.8 s |
Those are from a simulation of 4,800 frames with a two-second overhead per claim, not a benchmark on real hardware. The shape is what matters: the slower the slowest machine, the more the tail used to cost.
Where else this applies
The same three ideas fit any queue of work spread over uneven workers, from image processing to imports on several servers: check ownership when work is reported, parse identifiers strictly, and size work so the slowest worker cannot set the finishing time. All new fields are optional, so existing workers carried on unchanged while the new behaviour rolled out.