> 3) Fill gaps by pulling from the tail instead of rewriting the whole queue?
>
> I misunderstood at first—this is a generally helpful optimization.
> I'll integrate it into the current patch.
Great, thank you.
I dug deeper into the “fill gaps from the tail” optimization and implemented a version of it. The tricky part is not the copy itself but guaranteeing that the queue ends up hole-free and that tail really points at the slot after the last live request. With a twin-cursor gap-fill we refuse to move SYNC_FORGET_REQUEST / SYNC_FILTER_REQUEST (they’re order-sensitive fences).
If the final survivor is one of those barriers, the cursors meet while a hole still exists immediately before the barrier:
head → A [hole] FILTER(X) …unused…
If we then compute tail = (head + remaining_requests) % max_requests, the value lands inside the live region (on the barrier itself). The invariant (head + num_requests) % max_requests == tail is broken, so the next enqueue overwrites live data or the checkpointer under-scans the queue.
Alternatively, we may allow relocating SYNC_FORGET_REQUEST and SYNC_FILTER_REQUEST entries, but ensuring their ordering semantics remain correct would be quite challenging. That concern is why the implementation uses a forward-scan compaction. As the source comment noted:
/*
* The basic idea here is that a request can be skipped if it's followed
* by a later, identical request. It might seem more sensible to work
* backwards from the end of the queue and check whether a request is
* preceded by an earlier, identical request, in the hopes of doing less
* intervening SYNC_FORGET_REQUEST or SYNC_FILTER_REQUEST, so we do it
* this way.
Best,
Xuneng
