151–160 of 202 posts
Fun write up. Here’s another example of a binary patch to fix a Linux game issue: https://steamcommunity.com/app/333300/discussions/0/26463606...
Earlier quoted context omitted.
There are two points that I've made a couple times that are perhaps getting lost: 1. It's about blocking your logic flow, not about how the system is actually executing it or what the machine code resolves to. If a subsequent call is blocked on a previous one, then it's blocking. Spawning an async function or creating a new thread etc can be blocking, whereas what runs on it isn't (for your current thread). 2. Being…
I think you replied before I added 'Unless we want to say that 'nonblocking' is fake on non-RTOS systems, and not even try to define the term in that context. " Sure, the spec doesn't give a guarantee. But let's say it's impossible to give a guarantee on Linux. Is it really the best option to give up on defining 'nonblocking' entirely? Maybe we should formulate guarantees with an escape hatch for non-RTOS hazards. If…
And I agree, it would and therefore the definition is potentially meaningless. But pedantically it is blocking (but the functions called within it aren't to the current thread).
In a colloquial every day sense, I'd not be this pedantic. but this is a thread specifically about that pedantry.
End of the day, if I were talking colloquially, I'd only talk about expensive blocking calls as being blocking, regardless of IO when responsiveness is important. Otherwise it doesn't matter unless it's parallelizable and there are performance gains to be had.
Earlier quoted context omitted.
I think you replied before I added 'Unless we want to say that 'nonblocking' is fake on non-RTOS systems, and not even try to define the term in that context. " Sure, the spec doesn't give a guarantee. But let's say it's impossible to give a guarantee on Linux. Is it really the best option to give up on defining 'nonblocking' entirely? Maybe we should formulate guarantees with an escape hatch for non-RTOS hazards. If…
The only reason I mentioned that spawning threads/creating an async future is blocking is because you had mentioned that async would generate blocking assembly by my definition. And I agree, it would and therefore the definition is potentially meaningless. But pedantically it is blocking (but the functions called within it aren't to the current thread). In a colloquial every day sense, I'd not be this pedantic. but t…
If I was going for maximally pedantic but still useful definitions, I'd say that a "[non-]blocking syscall" is a different concept from how you'd describe running functions synchronously or asynchronously. And to elaborate, something like: Code that runs asynchronously is non-blocking, code that runs synchronously can be either blocking or non-blocking, and a syscall always has at least some synchronous code.
I like the idea of saying a syscall is non-blocking if the spec says it returns instantly. But I would add on to that, and say that if "this is not a real-time-OS" is the only reason the spec doesn't say it returns instantly, then we should call that non-blocking too. Or "non-blocking*" with a footnote that mentions RTOS issues.
You ask about getpid() taking a second. I'd say that within the model of "put those RTOS issues aside", that doesn't happen and can't happen. Just like we usually exclude unplugging the computer from our execution model, so too we exclude "linux isn't RTOS" from our execution model. getpid can't get stuck waiting on any resources, and does only trivial computation, so it will return immediately.
This reminds me of the recent Linus Tech Tips series on gaming on Linux[1]. Their conclusion is that although many games work out of the box (although usually not at launch), Linux is not ready for mainstream gamers. Not many people would have the expertise or the interest to troubleshoot the problem as OP did. [1] https://www.youtube.com/watch?v=Rlg4K16ujFw
Not many people have the expertise to do this on windows either(i would expect even fewer). Bear in mind that the developer sells this game as supported on Linux. The main reason is developers understandably don't care for bugs encountered by 2% users, which makes it a completely different discussion.
Earlier quoted context omitted.
Isn't this a native port though? I remember playing Papers Please even before it had a native port, and enjoying it with zero problems.
Apparently I got that wrong, point still stands though.
Earlier quoted context omitted.
> Windows isn't perfect or better for gaming. This assessment depends entirely on the perspective. From a developer's POV, Windows definitively is the better platform, as it's very monolithic in that you can rely on the presence and longevity of APIs. Depending on the dev's influence on the market and the success of the game, you even get free optimisation, support, and bug fixes from h/w vendors in the form of game-…
> you can rely on the presence and longevity of APIs That can be moot. Arguably, I can run more Windows games on Linux using Wine than on actual Windows, especially the older those games are. Optimizations or work on drivers done by outside developers isn't unusual for Linux too. In fact something like Cyberpunk 2077 became playable on Linux without CDPR getting involved, except for them providing the game to Mesa an…
So if you were a game developer you wouldn't consider the fact that for every 1 Linux gamer on Steam there are 99 Windows gamers and thus optimize for the much larger market?
Earlier quoted context omitted.
> you can rely on the presence and longevity of APIs That can be moot. Arguably, I can run more Windows games on Linux using Wine than on actual Windows, especially the older those games are. Optimizations or work on drivers done by outside developers isn't unusual for Linux too. In fact something like Cyberpunk 2077 became playable on Linux without CDPR getting involved, except for them providing the game to Mesa an…
> Overall I'd say Windows offers no advantages besides being more entrenched among gaming developers for historic reasons. So if you were a game developer you wouldn't consider the fact that for every 1 Linux gamer on Steam there are 99 Windows gamers and thus optimize for the much larger market?
With comparable market size, Linux won't be ignored either, its issues regardless.
Earlier quoted context omitted.
Or, io_uring the thing. One could probably wrap close() with LD_PRELOAD and not touch the binary...
While tempting, you can’t generally fix this by simply patching close() with some function that converts it to an unchecked asynchronous operation. If that were the case, you could just do that in the kernel. Close() is expected to complete synchronously. This matters because posix guarantees that open()/pipe() etc. will return the lowest file descriptor not in use[1]. I.e. this should work: close(0); fd = open(“/foo…
Earlier quoted context omitted.
Apparently I got that wrong, point still stands though.
It does if you sell on platforms that you don't intend to support.
Earlier quoted context omitted.
What the proposed patch does is delay a specific latent operation to an asynchronous context so that close() doesn’t block on that operation (which is freeing some memory). The proposed patch isn’t a comprehensive fix, it admits there are still other sources of relatively high close() latency. So that got me thinking, there is no way to fix this “bug” because there is no specification on how long close() should take…
close() is typically a blocking operation. But when it happens in devfs, procfs, tmpfs, or some other ram only filesystem I expect it to be fast unless documented otherwise.