Fixing stutters in Papers Please on Linux

No, blocking compute would be you doing something for a long period of time.

"open/close can block" means very little. You only need a mitigation if it ends up blocking long enough to be a problem in reasonable setups.

You do that have to care about what happens if someone runs the code on an intentionally terrible/horribly slow but technically in spec toy filesystem. No need to prematurely optimize for this scenario.

And especially with devfs you cannot just listen to POSIX and must know what the kernel is providing you - knowing how long operations take on such fds is normal design input.

For every system call you determine satisfies that principle, I could come up with a application level algorithm that is broken because of it. The principle is aspirational, Linux does a best effort as all Unix systems do not because Linux is buggy but because it can never be 100% given the spec. The core issue here was not close() taking 100ms or whatever it took, the core issue was doing unbounded work on the main drawing thread, which has strict timing requirements.

I agree that Linux use in general requires troubleshooting skill. We shouldn't assume there will never be any issues worth troubleshooting and recommend Linux to novices as a Microsoft killer. We should instead assume problems will happen and therefore a robust restore process is much more valuable to a novice Linux user.

This is why I believe in btrfs that Fedora uses. Imagine having the powerful restore options many Windows computers ship with. Just press a key, go into a menu, select a point in time recovery, restore.

But that said, what I really wanted to say was that I play exclusively on Linux now thanks to Proton and it's amazing. I can play big titles like Witcher 3, RDR2 and more, but I mostly play smaller titles like Oxygen not included, Rimworld and Ostriv.

It is important to not conflate POSIX requirements with expected behavior, especially for device files which require very specific knowledge of their implementation to use (DRM ioctl's and resources anyone?).

You might think that as a well-behaved game should not be opening/closing evdev fds during gameplay at all, this is clearly just an application bug. However, games are not the main user of evdev devices, your display server is! This bug causes input device closure during session switching (e.g. VT switching) to take abnormally long - on the machine I discovered the bug on, it ends up adding over a second to the session switch time, significantly impacting responsiveness.

This is absolutely a kernel bug. I did not push the patch further as I had other priorities, and testing this kind of patch is quite time-consuming when it only reproduces in a measurable way on single physical machine. Other machines end up with a much shorter synchronize_rcu wait and often have many fewer input devices, explaining why the issue was not discovered/fixed earlier.

call_rcu is intended to be used wherever you do not want the writer to block, while alternative fixes involve synchronize_rcu_expedited (very fast but expensive), identifying if the long synchronize_rcu wait is itself a bug that could be fixed (might be correct), or possibly refactoring evdev (which is quite a simple device file).

As for putting things in threads, I would consider it a huge hack to move open/close. Threads are not and will never be mandatory to have great responsiveness.

That criteria is established here - the OP is about an issue affecting paying end-users! Premature optimisation is not relevant - the software is failing.

It is unsafe to make fair-weather assumptions about customer systems.

Consider a common software failure: where the user is saving data to a SMB or NFS partition, and then there is a loss of connectivity to that file-server, and the developer has done whatever I/O they need on the main thread. This causes data loss.

You /should/ be able to assume (1) reliably fast return from core async-coordination syscalls (e.g. select, poll), and (2) that you will not suffer process or thread starvation caused by someone else. Respecting those constraints, it is good practice to isolate sync calls to a non-main thread in order to catch when they are not returning. This robustly covers both common scenarios (like the missing-filesystem) and obscure scenarios like the one in blog post.