1 Commits

Include renames

Author	SHA1	Message	Date
BZLZHH	4e48702f26	[Feat] (MG_Remote): a record can tell the server its answer will never be read - the bit works and cuts a frame's replies by 92%, and it proves the window's real blocker is the FIFO drain, not the pool depth ... The create window could not collect its deferred answers. The previous commit diagnosed that as the reply pool being 8 slots deep against 55,903 replies in one frame, and left a no-reply bit as the way out. This lands that bit, measures it on the device, and reports that the diagnosis was half wrong. WHAT LANDED. ClientSession::EmitAndWaitTails takes a second question beside wantReply: willReadReply. They are not the same question and the window is the case that separates them - it emits with wantReply=false and READS the answer later, so its records must still be answered. kRecNoReply (RingRecordFlags bit 5, which aliases kOptional in the call-flag space; the flag-space asserts were extended and the alias named) is stamped when willReadReply is false, and the decoder skips PostReply while keeping every acceptance counter - "nobody reads the answer" is not "nothing happened". The two illegal combinations are Fatal by name. Three call sites say it: SetTextureParams for a confirmed object, the respecify row's fire-and-forget half, and sub-data where MGPipeSubDataWantsItsReply decides. MEASURED ON THE DEVICE (aikjs4s8cys8ba7l, rebuilt APK + client, both halves new): server: skipped=50,001 answered=4,521 (a frame's replies: 55,903 -> 4,543) client: Reply frames received seen=4,501, latest seq=97,181 frame-sent: identical per op, records untouched create row: by_op 2 = 9,070 (was 4,536) - because the drain's blocking take is now counted, so the row's number stays honest instead of reading as "create stopped waiting" while the waiting merely moved AND THE WINDOW STILL READ BACK NOTHING: readfail 8,951 -> 8,872, i.e. -0.9%. THE REAL CAUSE, from the miss probe: P12miss n=1 want=310 replySeq=1504 ring=[1175..1504] P12miss n=9001 want=310 replySeq=102915 ring=[102866..102915] want=310 every time. The drain is STRICTLY FIFO and a failed read has no way out - it retries the same head for ever. Any reply buffer is bounded by design (8 pool slots, or the 8-frame ring the stream link now keeps), so with 4,536 deferred answers at least one is overwritten before it is read, and that one wedges the window permanently. Cutting the churn by two orders of magnitude does not help: it turns a certainty into a certainty. That is the constraint, not the depth. THE FIX IS NAMED AND NOT TAKEN (the goal this work ran under stops here on purpose). On a failed read of the head, abandon it: MGPipeNoteHandleUnpublished + NoteCreateSuspect + pop - the DECLINE path reused for "unknown". The window then self-heals through the blocking path and the object merely gets slower. It needs its own gate: a failed read must let the window ADVANCE. Gates, all green (172 + 13 + 22 + 103): PipeWireCodecTest.TheNoReplyBitSkipsTheAnswerAndKeepsTheAcceptanceRecord - the skip, the kept tally, the answered/skipped split, and the negative control that a record WITHOUT the bit is still answered (a server that stopped answering everything would otherwise pass) RemoteClientControls.ACreateWindowDefersTheAnswersAndTheWindowOffDoesNot - now also asserts the answers CAME BACK (answers_taken=11, outstanding=1, fallbacks=0 against 12 records). RED-ONCE PROVED: giving the window's creates the literal "fire-and-forget => skip" predicate makes this case fail. RingTest - the sixth and last flag alias, and the hand-written exhaustiveness list extended (with a note that it is only as exhaustive as that list). Server side: AnsweredRecords()/SkippedAnswers() - the number that made this debuggable, since a wire change whose effect is invisible is undebuggable. Client-first is safe: an old server ignores bit 5 and replies as before, so the two cross-version directions degrade to today's behaviour - this is "both ends must upgrade to take EFFECT", not "to avoid breaking". Hit that in practice first.	2026-09-26 02:00:44 +08:00