mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-03 11:15:20 +02:00
Henrik RydgårdandClaude Sonnet 5
c32df3d931
CPUCoreSubscriber through the CPU thread Continues the pattern started with SteppingSubscriber: route breakpoint, disassembly, symbol, and register access through Core_RunOnCPUThread() instead of touching that state directly from the WebSocket handler thread. Two intentional exceptions, matching the reasoning already used for cpu.stepInto's "not currently stepping" branch: - cpu.stepping's Core_Break() call stays unqueued - it's what makes the CPU thread start reaching the queue drain point in the first place. - cpu.status stays unqueued - it's meant to be a cheap, frequently-pollable status check, and its "pc" field is already documented as inaccurate unless stepping. Matches how SteppingBroadcaster already reads the same state directly from the WebSocket thread. Where a handler's response doesn't depend on anything the queued lambda computed (plain add/remove endpoints), moved req.Respond() back out after the Core_RunOnCPUThread() call for readability - the JSON building and socket write happen later in Finish() regardless of where Respond() is called, so there's no thread-safety difference either way, just clarity about what actually needs to run on the CPU thread. memory.searchDisasm carries the same caveat flagged for memory.search: its scan range has no size cap, so if the CPU is stepping, a very large range will now block the CPU thread's own frame pump for the scan's duration rather than running unqueued on the WebSocket thread as before. Not fixed here - noted in a comment at the call site. Replaced remaining `auto` locals in these three files with concrete types. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hqm11k99viLfbJm2MkH4BH