4 ms·

> I would say this code fails the principle, independent of particular application problems. For every system call you determine satisfies that principle, I co

> I would say this code fails the principle, independent of particular application problems. 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.

Dylan16807 5y ago
They're both problems. This slowness is approaching the point where even checking for joysticks on a dedicated thread would start having delay problems. And spawning a thread per file would be ridiculous and would get even more scorn if it was slow, "why are you spawning so many threads, of course that's not efficient".
- CyberRabbi 5y ago
  > This slowness is approaching the point where even checking for joysticks on a dedicated thread would start having delay problems. Poorly designed code will perform poorly. Well designed code won’t have delay problems. > And spawning a thread per file would be ridiculous and would get even more scorn if it was slow, Where in this entire thread was it suggested to spawn a thread per file? Threads are able to perform more than a single unit of work.
  - Dylan16807 5y ago
    > Poorly designed code will perform poorly. Well designed code won’t have delay problems. If I need to open and close 20 files every few seconds, and they all might have unpredictable latencies, even the best designed code in the world could have delay problems. > Where in this entire thread was it suggested to spawn a thread per file? You just implied that checking all the files on a dedicated thread is still 'poorly designed code', didn't you? So if a dedicated thread for the whole group of files isn't enough, sounds like you need to move to a thread per file. Unless it's wrong to use close() at all, or something? You can only blame the code so much.

Dylan16807 5y ago

They're both problems. This slowness is approaching the point where even checking for joysticks on a dedicated thread would start having delay problems. And spawning a thread per file would be ridiculous and would get even more scorn if it was slow, "why are you spawning so many threads, of course that's not efficient".

CyberRabbi 5y ago
> This slowness is approaching the point where even checking for joysticks on a dedicated thread would start having delay problems. Poorly designed code will perform poorly. Well designed code won’t have delay problems. > And spawning a thread per file would be ridiculous and would get even more scorn if it was slow, Where in this entire thread was it suggested to spawn a thread per file? Threads are able to perform more than a single unit of work.
- Dylan16807 5y ago
  > Poorly designed code will perform poorly. Well designed code won’t have delay problems. If I need to open and close 20 files every few seconds, and they all might have unpredictable latencies, even the best designed code in the world could have delay problems. > Where in this entire thread was it suggested to spawn a thread per file? You just implied that checking all the files on a dedicated thread is still 'poorly designed code', didn't you? So if a dedicated thread for the whole group of files isn't enough, sounds like you need to move to a thread per file. Unless it's wrong to use close() at all, or something? You can only blame the code so much.