Merging upstream FlashML-org/FreeToken#588 (d3512b4) as-is deadlocks the filler-thread PLE graph fill (fork #67) at decode step 2 #78

Merge hazard for any branch that carries fork #67 (the filler-thread PLE fill, issue #65), such as 1080deploy.

Upstream FlashML-org#588 (d3512b4, now on upstream main) adds a graph fence to DiskRowTable in python/freetoken/models/qwen4_exp/ple_disk.py:

• forward_host_ctx records _graph_consumed on the current stream after each graph launch returns.
• fill(graph=True) calls _graph_consumed.synchronize() before it writes _graph_pinned.

Upstream runs the graph fill after the launch returns, so the fence is sound there.

With fork #67, the graph fill is a job on the ple-filler thread, submitted before cuGraphLaunch. The launch's WAIT is released only by that fill's flag write. A fence recorded after launch k therefore makes fill k (or k+1, whichever reaches synchronize() after the record) wait on graph k, and graph k waits on that fill. Decode hangs on the second overlapped step.

The textual conflict is one hunk in forward_host_ctx. Taking "ours plus upstream's record after the yield" produces exactly the hanging version.

Resolution used on 5080deploy (#75):

• Keep fork 5080deploy: run the PLE graph fill on its own thread, submitted before the launch (fixes #65) #67's forward_host_ctx.
• Keep fix(ple): fence disk staging against in-flight lookups FlashML-org/FreeToken#588's eager double buffer (_eager_pinned[2], _eager_read events). That half fixes a real eager-fill race, and its upstream GPU test fails on the old code.
• Delete _graph_consumed entirely.

The fence is redundant here. The wait-sync job synchronizes a readback event recorded after the previous graph in stream order (per-fill since 1080deploy 79988cc/198574d). Launch-gating does a blocking D2H of batch.input_ids before its fill.

Regression test: tests/models/qwen4_exp/test_ple_disk_no_graph_fence.py (5080deploy, #77) drives 12 overlapped graph decode steps against an asynchronous in-order fake stream.

• It passes on the resolution.
• With the fence restored, it fails with TimeoutError: a fill waited on stream position 2, which never completed.

For 1080deploy: its ple_disk.py already has FlashML-org#548 and the per-fill events but not FlashML-org#588. When it merges d3512b4, resolve the same way and take the test.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bu6LgoxLR4wETqb7RPR2vt