4 ms·
> It's perfectly valid for the OS to swap your program instructions to disk, and then take seconds or even minutes to load it back. It’s not valid to swap your
by CyberRabbi 5y ago
> It's perfectly valid for the OS to swap your program instructions to disk, and then take seconds or even minutes to load it back.
It’s not valid to swap your program instructions to disk if you call mlock() on your executable pages. Indeed, performance sensitive applications do just that. https://man7.org/linux/man-pages/man2/mlock.2.html https://man7.org/linux/man-pages/man2/mlock.2.html
> It's effectively impossible to avoid depending on what you call "luck". The OS does not provide nearly enough guarantees to build useful interactive applications without also depending on other reasonable performance expectations.
This is all self-evidently false. You likely wrote your comment on a POSIX-based interactive application. It just takes knowledge of how the system works and what the specifications are. Well-designed programs are hard to come by but they do exist.
- slavik81 5y agoDoes mlock itself have a guaranteed maximum execution time? Is it guaranteed to return success under the relevant conditions? While that is an excellent way to address the problem I mentioned, you still have to depend on more than just the guaranteed behaviour of the OS. > You likely wrote your comment on a POSIX-based interactive application. It just takes knowledge of how the system works and what the specifications are. I wrote my comment on an interactive POSIX application, yes, but I believe my browser depends on "reasonable performance" of OS-provided functions in order to be usable. It would be a fun exercise to evaluate such a program that supposedly did not. For any given program, I suspect I could patch the Linux kernel in such a way that the kernel still fulfilled all guaranteed behaviour while still making the program unusable.