https://gitlab.synchro.net/main/sbbs/-/work_items/1176#note_10548
The CPU use comes from SVDM's main loop in `src/vdmodem/vdmodem.c`, which never blocks with the default settings:
- **Idle, waiting for a call:** the loop waits on the DOS process handle with a timeout of `MainLoopDelay`, which defaults to 0. So it returns immediately, polls the mailslot and ring state, and spins one logical CPU at 100%. On an 8-thread machine that shows as the 12-15% total in the screenshot.
- **Connected but idle:** the socket `select()` timeout is `SocketSelectTimeout`, which also defaults to 0, so the loop still spins.
- **Active call with a `Rate` set:** while received data waits for the rate-pacing interval, `select()` returns immediately every pass. Even with both settings raised, the loop spins until that interval passes.
Both settings were added in 5fd72f315e (2024-03-25) as opt-in knobs with a default of 0.
**Workaround for the current build:** add `MainLoopDelay=1` (and optionally `SocketSelectTimeout=1`) to the root section of `svdm.ini`. Idle CPU should drop to near zero.
**Fix in progress (SVDM v0.7, not yet committed):** every pass of the main loop now blocks somewhere:
- **Idle / command mode:** it waits on the process handle for at least 1 ms.
- **Online:** it blocks in `select()` for `SocketSelectTimeout` (new default: 1 ms). Incoming network data still wakes it immediately.
- **Rate pacing:** it waits out the remaining pacing interval instead of spinning.
An explicit `SocketSelectTimeout=0` restores the old spin-wait behavior for anyone who wants it. Data from the DOS program is still polled from the mailslot, so its added latency is at most one Windows timer tick (about 15 ms).
@xbit, once a build is available, could you report idle, connected-idle and active-call CPU usage with `Debug=false`?
— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
