3 ms·

> If the operation can be done without blocking, it will be completed synchronously in the context of the calling thread. My careers been in mobile, I thought

> If the operation can be done without blocking, it will be completed synchronously in the context of the calling thread. My careers been in mobile, I thought “blocking” and “synchronous” were synonymous. Does blocking in this context mean “needs to make a system call?”

skulk 3y ago
I think it means "entering a state where the thread has nothing to do but wait." An "add" instruction is synchronous but I wouldn't say it "blocks".
- Arnavion 3y ago
  >I think it means "entering a state where the thread has nothing to do but wait." No. Neither thread involved here (the userspace thread or the kernel thread) will "wait" in either scenario. The userspace thread will either work on the syscall (because it was ready to be performed immediately) or it will be released to go do something else. The kernel thread will either not be involved (because the syscall was performed by the userspace thread already) or it will start working on the syscall.
deleted 3y ago
[deleted]
Arnavion 3y ago
"Blocking" == "can be completed immediately" in this context, ie whether the equivalent syscall would complete immediately or if it would return EAGAIN. So if the operation can be completed immediately, it will be completed in the context of the calling thread without involving the kernel work queue. Otherwise it cannot be completed immediately, so the kernel work queue will take it and start working on it.
ithkuil 3y ago
"Blocking (on IO)" in OS jargon means that the thread can yield the CPU to other threads because it's otherwise waiting for some external event (e.g. some IO operation to complete). When the IO operation is ready the thread is then marked to be awakened and the scheduler will context switch back to it whenever it sees fit (given other considerations like thread priority, etc). From the POV of the thread that blocks nothing really happens while it's waiting. Once it awakens it has the result of the operation (or an error) and it can observe that more time has passed by inspecting the timer. For all intents and purposes the operation was "synchronous" from the POV of the thread.
- refulgentis 3y ago
  Ty for this, Flutters been unreasonably effective for me, with an absurdly simple concurrency system, and I never quite understood why. Now I see why the simple idea of never-blocking is so effective. This comment probably sounds silly, I’m groping for words to describe my old vs. new understanding, but anyways, thanks :)

skulk 3y ago

I think it means "entering a state where the thread has nothing to do but wait." An "add" instruction is synchronous but I wouldn't say it "blocks".

Arnavion 3y ago
>I think it means "entering a state where the thread has nothing to do but wait." No. Neither thread involved here (the userspace thread or the kernel thread) will "wait" in either scenario. The userspace thread will either work on the syscall (because it was ready to be performed immediately) or it will be released to go do something else. The kernel thread will either not be involved (because the syscall was performed by the userspace thread already) or it will start working on the syscall.

deleted 3y ago

[deleted]

Arnavion 3y ago

"Blocking" == "can be completed immediately" in this context, ie whether the equivalent syscall would complete immediately or if it would return EAGAIN. So if the operation can be completed immediately, it will be completed in the context of the calling thread without involving the kernel work queue. Otherwise it cannot be completed immediately, so the kernel work queue will take it and start working on it.

ithkuil 3y ago

"Blocking (on IO)" in OS jargon means that the thread can yield the CPU to other threads because it's otherwise waiting for some external event (e.g. some IO operation to complete). When the IO operation is ready the thread is then marked to be awakened and the scheduler will context switch back to it whenever it sees fit (given other considerations like thread priority, etc). From the POV of the thread that blocks nothing really happens while it's waiting. Once it awakens it has the result of the operation (or an error) and it can observe that more time has passed by inspecting the timer. For all intents and purposes the operation was "synchronous" from the POV of the thread.

refulgentis 3y ago
Ty for this, Flutters been unreasonably effective for me, with an absurdly simple concurrency system, and I never quite understood why. Now I see why the simple idea of never-blocking is so effective. This comment probably sounds silly, I’m groping for words to describe my old vs. new understanding, but anyways, thanks :)