3 ms·

> What resource? I did my best to look at the implementation, but the source code is complicated and scattered. I can't really process your link by itself. How

> What resource? I did my best to look at the implementation, but the source code is complicated and scattered. I can't really process your link by itself. How often are these things causing delays? A signal may need to be invoked and that could cause paging to disk. The point is that the kernel is allowed to do a non-predictable amount of work on most system calls and therefore you cannot assume getpid() completes in any amount of time. If you’re building a real time interactive system, then this matters. If you’re building a system that’s allowed to be non-responsive (for running batch processes, network servers) then it doesn’t.

Dylan16807 5y ago
People are going to keep using non-realtime systems to run soft realtime UIs. We can't make them stop, so it's still important to distinguish between "this syscall might hit a signal or an interrupt, just like every single line of code in the program" and "this syscall might hit a signal or an interrupt, but also it might get stuck waiting on a resource in a way that couldn't have otherwise happened". If you want to suggest different terms from "nonblocking" and "blocking" I'm open to change. But in the absence of better terms, I'm going to keep using those, with an asterisk that says I'm inside linux and literally anything could technically block.
- CyberRabbi 5y ago
  > People are going to keep using non-realtime systems to run soft realtime UIs. Very true and if they want their applications to work well they should write they applications correctly!
  - Dylan16807 5y ago
    The best way to help them write applications correctly is not to say "all syscalls are blocking, none are nonblocking, no other categories".
    - CyberRabbi 5y ago
      There are categories, some system calls block on timers, some block on disk io, some block on network io. But they all block, except for gettimeofday() and friends.
      - Dylan16807 5y ago
        I mean I wouldn't say gettimeofday is significantly better than getpid because your thread might switch out anyway. But sure five categories is fine, I just dislike lumping almost everything together.

Dylan16807 5y ago

People are going to keep using non-realtime systems to run soft realtime UIs. We can't make them stop, so it's still important to distinguish between "this syscall might hit a signal or an interrupt, just like every single line of code in the program" and "this syscall might hit a signal or an interrupt, but also it might get stuck waiting on a resource in a way that couldn't have otherwise happened". If you want to suggest different terms from "nonblocking" and "blocking" I'm open to change. But in the absence of better terms, I'm going to keep using those, with an asterisk that says I'm inside linux and literally anything could technically block.

CyberRabbi 5y ago
> People are going to keep using non-realtime systems to run soft realtime UIs. Very true and if they want their applications to work well they should write they applications correctly!
- Dylan16807 5y ago
  The best way to help them write applications correctly is not to say "all syscalls are blocking, none are nonblocking, no other categories".
  - CyberRabbi 5y ago
    There are categories, some system calls block on timers, some block on disk io, some block on network io. But they all block, except for gettimeofday() and friends.
    - Dylan16807 5y ago
      I mean I wouldn't say gettimeofday is significantly better than getpid because your thread might switch out anyway. But sure five categories is fine, I just dislike lumping almost everything together.