mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-30 09:25:13 +02:00
Henrik RydgårdandClaude Opus 5
6175fab373
Core_ProcessStepping() returns immediately when the CPU is stopped with nothing queued, so Core_RunLoopUntil() returns immediately, so whatever drives it comes straight back. headless does that in a loop with no frame pacing at all, so a paused emulator sat at 100% of a core: measured 6.02 CPU-seconds over 6 wall seconds parked at startBreak. A debugger session is stopped most of the time, so this also dominated any profile taken of one - showing up as synchronization overhead around Core_RunOnCPUThread, which was just the hottest thing inside the spin rather than a problem with the queue. The CPU thread now blocks on a condition variable in that case. Anything that gives it something to do wakes it - Core_RunOnCPUThread() on push (with the queue mutex held, so it can't sleep on a task already queued), Core_RequestCPUStep(), and Core_Resume() - so the 2ms timeout is only a backstop for state changed without a wake, never how work is normally noticed. The wait is deliberately short rather than indefinite: callers do real work after Core_RunLoopUntil() returns, and in the app build that includes rendering the ImGui debugger from this same thread, so this has to bound how long a paused frame takes rather than replace the frame loop. Now 0.05 CPU-seconds over the same 6 seconds. No measurable cost to anything else: an identical scripted boot runs in 2514ms vs 2476ms before, and 20 consecutive cpu.stepInto still complete promptly. 55 unit tests pass, 314/314 pspautotests with --graphics=software. Also: wsdbg's README claimed a raw JSON line gets a ticket auto-assigned when it lacks one. It doesn't - the code deliberately sends raw lines exactly as written, and omitting the ticket is how you say "not waiting for an answer". Corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9