mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-16 07:50:28 +02:00
libretroadmin
f1208a7a5a
The core and the headless tools no longer use mutexes, condition variables, spinlocks, std::atomic, std::thread or volatile flags. Threads hand off through libretro-common's retro_atomic and rthreads plus a few small pieces on top of them in Common/Thread: Thread, MpscQueue, EventCounter, ParkingLot waits and ReaderGate. Every wait blocks until it's woken; nothing polls on a timer. State that only one thread touches just loses its lock. The PSP filesystem, sceIo and the savedata dialog now belong to the emulation thread: async reads and writes run when they're queued and complete later in emulated time, and the IO and savedata threads are gone. The friend finder only talks to the adhoc server and hands what it gets to the emulation thread. GPU init always runs on the thread that starts the game. The Vulkan render and compile queues, pipeline and render pass caches, delete list and SPIR-V cache, the GL render queue, the software renderer's jit caches, the file loader caches, the web debugger, UPnP, input, savestates, logging and the GE debugger all hand off through queues and atomics. The IR jit's spinning profiler thread goes. A CPU thread with nothing to run now sleeps until work is queued instead of spinning. Headless with --debugger waits for a client while stopped, and ends the run once every client that connected has left. Web server shutdown keeps servicing the CPU queue until the server has finished.
3.5 KiB
3.5 KiB
Debugger threading model
Which thread may touch what in the WebSocket debugger (headless builds; the libretro core doesn't
build it). Read this before touching Core/Debugger/WebSocket*, Core/WebServer.cpp or anything
else that reaches into core state from outside the CPU thread.
There are no locks here, and none should come back. State has one owner; other threads hand it work or messages.
Threads
- CPU thread - runs
Core_RunLoopUntil()and owns all emulator state, including the debugger's (g_breakpoints,g_symbolMap,g_disassemblyManager,MIPSAnalyst's function tables, theMemBlockInfoslab maps, registers, memory, kernel objects). - Web server thread (
Core/WebServer.cpp) - blocks inhttp::Server::RunSlice()on the listening socket and the server'snet::CancelToken, with no timeout.ShutdownWebServer()cancels the token, which wakes the accept loop and every connection, then joins the thread. - Connection threads - one per request (
NewThreadExecutor). A debugger session runsHandleDebuggerRequest()there. The server thread joins them all before it exits.
Rules
- Emulator state is accessed only inside
Core_RunOnCPUThread(func)(Core/Core.h). It queuesfuncfor the CPU thread and blocks until it has run (inline if already on the CPU thread). Put the validity checks (isAlive(),IsValidAddress()) inside the callback too; answering them outside means acting on a stale answer. - Never make the CPU thread wait for a thread that may be waiting on the CPU thread. A
Core_RunOnCPUThread()callback must not block on a connection. The queue is drained only while the CPU loop runs, so don't rely on it where the loop may never run again (shutdown paths). - Events the emulator produces on its own are pushed, never polled. Each connection has a
DebuggerEventSink(aDebuggerMailbox, seeWebSocketUtils.h): an MPSC inbox of formatted events plus a wake socket.WebSocketDebuggerTick(), called fromCore_ProcessCPUQueue()on the CPU thread, notices transitions (game.*,cpu.stepping,input.buttons/input.analog, finishedinput.buttons.press) and posts them; breakpoint hits are posted fromWebSocketNotifyBreakpointHit(). Don't add a broadcaster that reads emulator state from the connection thread. - A connection blocks until something happens: socket readable/writable, its sink woken, or the
server stopping (
WebSocketServer::Process(wakeFds, count), no timeout). Producers publish first, then callmailbox->Wake(); wakes are coalesced with a pending flag, and the connection rearms (drains the socket, then clears the flag) before looking at its queues. - Subscribers fed from another thread (
GPUStatsSubscriber's flip listener,GPURecordSubscriber's record callback) push into their own MPSC queue and callmailbox->Wake(); theirBroadcast()drains it on the connection thread. Log messages arrive the same way (LogBroadcaster). - Sinks are refcounted: the connection and the CPU thread's list each hold one reference, so a callback on the CPU thread can still post after the connection has left.
Memory tagging
NotifyMemInfo*() may be called from any thread (CPU thread, software rasterizer workers, the SAS
thread). Notifications go into an MPSC queue; the slab maps belong to the emulation thread, which
drains the queue before every lookup (FindMemInfo*, FormatMemWriteTagAt), on every flip, and for
savestates. Lookups are emulation-thread only.