mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-01 02:05:21 +02:00
Henrik RydgårdandClaude Sonnet 5
c6fccefa49
The WebSocket debugger's cpu.stepInto handler ran entirely on the WebSocket handler thread, directly manipulating breakpoints and stepping state (via Core_RequestCPUStep, g_breakpoints.SetSkipFirst, etc.) that's otherwise only ever touched from the CPU thread (the one that calls Core_RunLoopUntil, and thus indirectly NativeFrame). Adds Core_RunOnCPUThread() - queues a function to run on the CPU thread and blocks the caller until it's done. The queue is drained at the top of Core_RunLoopUntil()'s loop, so it's reached continuously (in a tight spin) while the CPU is stepping/paused, and at least once per call even while fully running. cpu.stepInto is the first consumer: once the CPU is already stepping, the breakpoint/stepping manipulation is now routed through Core_RunOnCPUThread instead of happening directly on the WebSocket thread. The "not currently stepping" path still calls Core_Break() directly from the WebSocket thread, since it's already documented free-threaded and is what makes the CPU thread start reaching the queue-drain point in the first place. More WebSocket debugger commands can be converted the same way going forward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hqm11k99viLfbJm2MkH4BH