mirror of
https://github.com/stablyai/orca.git
synced 2026-09-29 16:02:50 +00:00
Orca Worker
011122d833
MDE flags "suspicious memory activity" on the process-table reader: it opened a handle into every process on the box and read each one's PEB on a repeating cadence. Two changes narrow that. Drop `Memory` outright. It cost a second OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ) plus GetProcessMemoryInfo per process, and nothing reads a working set off this table -- the Resource Manager runs its own sweep, and the addon stores WorkingSetSize into a DWORD so anything above 4 GB wraps. Split the rest in two. `readWindowsProcessIdentityTable[Fresh]` is a bare Toolhelp32 walk with zero per-process handles, and returns `WindowsProcessIdentityRow`, which has no `command` to read. `readWindowsProcessTable[Fresh]` keeps the command line for the callers that match on it. PTY root identity and the owner start-time probe move to the cheap reader; agent recognition, port attribution, codex turn processes and structured-TUI matching all genuinely need the command line and stay. Two independently single-flighted caches, never one per caller: the fan-out this module prevents is one scan per caller, and each reader still serves every caller wanting its flag set. The wedge gate and the 3s deadline stay shared, because both readers call the same addon and one wedged read latches its one `requestInProgress`. With no binding there is only the 1.4s PowerShell scan to run, so the identity view rides the detailed snapshot rather than forking a second one. Measured on Windows 11, 492 processes (p50/p95): identity 6.3/7.0 ms, detailed 12.3/13.4 ms, previous memory+commandLine 13.1/14.1 ms.