> poll/read/write The “non-blocking” nature of those calls were invented for network servers, not for video games. Not only is jitter tolerable there but high

> poll/read/write The “non-blocking” nature of those calls were invented for network servers, not for video games. Not only is jitter tolerable there but high latency is allowed from the lowest layers of the stack. It’s not uncommon to simply get no response from a network request. A video game should never ever do arbitrary system calls on its main drawing thread unless those system calls are specifically intended for that use case. Jitter is not tolerable in this use case since the timing requirements are so strict. The code must product a frame every 16.6ms, no exceptions. The interface must never become unresponsive. > RTOS does not guarantee that system calls do not block RTOSes do indeed provide upper bounds for all calls. > And, again, when interacting with device files you must refer to the kernel documentation rather than POSIX Yes that would be a relevant point if it were the case that the kernel documentation for these devices specified that close() should complete within some time bound.