SDL_PollEvent busy‑wait causing high CPU usage in idle loops

When an SDL application runs its main loop with SDL_PollEvent while no input is pending, the function returns immediately and the loop can spin continuously, potentially consuming a full CPU core. This behavior may hide performance problems in rendering or audio subsystems because the observed CPU usage is dominated by the event‑polling loop itself. Developers must decide whether to accept the constant CPU load, insert a delay, or switch to SDL_WaitEvent, each choice affecting latency, power consumption, and thread‑safety guarantees that are implementation‑defined.

What level of CPU usage is acceptable for an idle SDL_PollEvent loop? Does adding a minimal SDL_Delay sufficiently reduce the load without introducing noticeable input lag? How does the thread‑safety of concurrent SDL_PollEvent calls influence the decision to serialize access or use a dedicated input thread?