6 ms·

CyberRabbi's definition of blocking is correct and what I've always seen commonly accepted. Blocking means you don't know how long it'll take, and you want to

by dagmx 5y ago

CyberRabbi's definition of blocking is correct and what I've always seen commonly accepted. Blocking means you don't know how long it'll take, and you want to wait for it to finish. The only safe assumption is that you cannot guarantee how long it'll take. getpid is accurately therefore a blocking call. You don't know how long it'll take. You can profile and make best guesses, but you can never assuredly say how long it'll take.

vanviegen 5y ago
I'd say that the commonly accepted definition for a blocking call is one that may depend on I/O to complete, releasing control of the CPU core while waiting. By that definition, getpid() is definitely nonblocking, though it doesn't have an upper bound in execution time. POSIX does not offer hard realtime guarantees. close() in general would probably be blocking (as a filesystem may need to do I/O), but I'd expect it to behave nonblocking in most cases, especially when operating on virtual files opened read-only. Unfortunately, I don't think those kinds of behavioral details are documented.
- dagmx 5y ago
  A function that sleeps for 5 seconds is blocking. No IO involved. Blocking just means that you're blocking your current code till you return out of the called function. Anything else regarding a function call is an assumption unless you know the exact implementation.
loeg 5y ago
Every operation in a non-RTOS is blocking by this definition, even local function calls that don’t enter the kernel, because the kernel may switch to another thread at any time. It’s utterly useless as a definition. Much more common is to divide system calls into ones that call depend on some external actor and those that don’t. Eg, recv() on a socket, blocking on a futex held by some other process, or waiting on IO to some disk controller. Getpid() is synchronous but does not block.
- CyberRabbi 5y ago
  Blocking in that sense is usually used in relation to some event. E.g. sleep() blocks on a timer, read() blocks on IO, etc. In the general sense, it means that the call has an indefinite run time. E.g. “this call blocks” = “this call could take an arbitrarily long amount of time” getpid() is blocking but it likely does not block on IO (though it could as that is allowed by the spec).
- dagmx 5y ago
  If you call getpid, or even local functions, can the rest of your code (in a single thread) continue till getpid returns? E.g if you do this inside a function (useless code) int pid = getpid(); std::cout << pid+2 << std::endl; Will the output print even if the hypothetical call to getpid takes a second? If the answer is the print will wait, then it's a blocking call. If it was an async call, then it could happen concurrently or in parallel, and unless you waited, it would continue on in a non blocking fashion. Waiting for a return == blocking. It may be quick but unless the spec specifies that it must be synchronous+non-blocking, the distinction between the two is moot.
  - deleted 5y ago
    [deleted]
  - Dylan16807 5y ago
    But with such an extreme definition, can you even show me what an an async non-blocking syscall would look like? Because I'm going to point at the assembly instructions that pass the parameters, and say "an interrupt happens here, delaying it for 1 second". Any definition of blocking that includes "int fifty() {return 50;}" strikes me as having problems. More specifically, I'd say there's some amount of "kernel does a thing" that needs to be excusable when you're talking about whether a syscall is blocking or not, otherwise everything is blocking. Unless we want to say that 'nonblocking' is fake on non-RTOS systems, and not even try to define the term in that context.
    - dagmx 5y ago
      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 blocking or not is independent of performance. A blocking function call can be near instant, it may get inlined, it may take a year to run. Similarly an async or non blocking call can also have the same time complexity. The issue is that if the spec doesn't say it returns instantly, or you don't know for sure that it does, you can't guarantee that the blocking time will be short enough to be acceptable. So while getpid or close will almost always return instantly, it's still blocking. And if the spec doesn't say it's guaranteed, then the performance acceptability in the hot path can change. End of the day it's all just (often pedantic) semantics to let people describe the execution nature of things so devs can make the best decisions for their performance needs.

by dagmx 5y ago

vanviegen 5y ago

I'd say that the commonly accepted definition for a blocking call is one that may depend on I/O to complete, releasing control of the CPU core while waiting. By that definition, getpid() is definitely nonblocking, though it doesn't have an upper bound in execution time. POSIX does not offer hard realtime guarantees. close() in general would probably be blocking (as a filesystem may need to do I/O), but I'd expect it to behave nonblocking in most cases, especially when operating on virtual files opened read-only. Unfortunately, I don't think those kinds of behavioral details are documented.

dagmx 5y ago
A function that sleeps for 5 seconds is blocking. No IO involved. Blocking just means that you're blocking your current code till you return out of the called function. Anything else regarding a function call is an assumption unless you know the exact implementation.

loeg 5y ago

Every operation in a non-RTOS is blocking by this definition, even local function calls that don’t enter the kernel, because the kernel may switch to another thread at any time. It’s utterly useless as a definition. Much more common is to divide system calls into ones that call depend on some external actor and those that don’t. Eg, recv() on a socket, blocking on a futex held by some other process, or waiting on IO to some disk controller. Getpid() is synchronous but does not block.

CyberRabbi 5y ago
Blocking in that sense is usually used in relation to some event. E.g. sleep() blocks on a timer, read() blocks on IO, etc. In the general sense, it means that the call has an indefinite run time. E.g. “this call blocks” = “this call could take an arbitrarily long amount of time” getpid() is blocking but it likely does not block on IO (though it could as that is allowed by the spec).
dagmx 5y ago
If you call getpid, or even local functions, can the rest of your code (in a single thread) continue till getpid returns? E.g if you do this inside a function (useless code) int pid = getpid(); std::cout << pid+2 << std::endl; Will the output print even if the hypothetical call to getpid takes a second? If the answer is the print will wait, then it's a blocking call. If it was an async call, then it could happen concurrently or in parallel, and unless you waited, it would continue on in a non blocking fashion. Waiting for a return == blocking. It may be quick but unless the spec specifies that it must be synchronous+non-blocking, the distinction between the two is moot.
- deleted 5y ago
  [deleted]
- Dylan16807 5y ago
  But with such an extreme definition, can you even show me what an an async non-blocking syscall would look like? Because I'm going to point at the assembly instructions that pass the parameters, and say "an interrupt happens here, delaying it for 1 second". Any definition of blocking that includes "int fifty() {return 50;}" strikes me as having problems. More specifically, I'd say there's some amount of "kernel does a thing" that needs to be excusable when you're talking about whether a syscall is blocking or not, otherwise everything is blocking. Unless we want to say that 'nonblocking' is fake on non-RTOS systems, and not even try to define the term in that context.
  - dagmx 5y ago
    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 blocking or not is independent of performance. A blocking function call can be near instant, it may get inlined, it may take a year to run. Similarly an async or non blocking call can also have the same time complexity. The issue is that if the spec doesn't say it returns instantly, or you don't know for sure that it does, you can't guarantee that the blocking time will be short enough to be acceptable. So while getpid or close will almost always return instantly, it's still blocking. And if the spec doesn't say it's guaranteed, then the performance acceptability in the hot path can change. End of the day it's all just (often pedantic) semantics to let people describe the execution nature of things so devs can make the best decisions for their performance needs.