mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-07 05:03:35 +02:00
--sync could only match a response to a request that carried a ticket, and wsdbg only assigned tickets to its key=value shorthand. A raw JSON line - the only way to send nested parameters, so unavoidable for broadcast.config.set and similar - got none, so --sync had nothing to match on and skipped waiting for that line entirely. The next line then went out immediately and its response could be read as this one's, quietly desynchronising the rest of the script. Nothing reported an error; the output just stopped meaning what it appeared to. Raw lines now get a ticket assigned when they don't carry one, and are checked before being sent: not valid JSON, not an object, no string 'event', or a 'ticket' that isn't an integer are all refused with a specific message rather than shipped off to fail somewhere downstream. A refused line fails the run. The waiting logic also drops its special case for events that "never respond". That's no longer true - every request is acknowledged now - so the ticket is always the thing to wait for. RESUME_FAMILY events additionally wait for the following cpu.stepping, which only counts once the acknowledgement has been seen, so a stepping event still in flight from something earlier can't be mistaken for this command's. An error reply ends the wait immediately instead of hanging until the timeout for a cpu.stepping that will never come. cpu.runUntilTime joins that family, so --sync alone now blocks until it really arrives - no :wait needed. A --sync timeout is reported with the event and ticket it gave up on, and makes the run exit non-zero. Verified against CrossCraft: a script of nothing but commands (no :sleep, no :wait) runs to exactly 1200000us, chains a relative 300000us to land on 1500000us, and returns immediately on a rejected target instead of stalling. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9