4 ms·

I'm confused, and please correct me if I'm wrong. Aren't all these calls blocking? Doesn't `File.read` still block? Sure it's multithreaded, but it still block

by fny 2y ago

I'm confused, and please correct me if I'm wrong. Aren't all these calls blocking? Doesn't `File.read` still block? Sure it's multithreaded, but it still blocks. Threading vs an event loop are two different concurrency models.

masklinn 2y ago
> Aren't all these calls blocking? Only locally, which is pretty much the same as when you `await` a call. > Threading vs an event loop are two different concurrency models. The point is that you can build a "threading" (blocking) model on top of an event loop, such that you get a more natural coding style with most of the gain in concurrency. It loses some, because you only have concurrency between tasks (~threads) leaving aside builtins which might get special cased, but my observation has been that the vast majority of developers don't grok or want to use generalised sub-task concurrency anyway, and are quite confused when that's being done. For instance in my Javascript experience the average developer just `awaits` things as they get them, the use of concurrent composition (e.g. Promise.all) is an exception which you might get into as an optimisation, e.g. `await`-ing in the middle of a loop is embarrassingly common even when the iterations have no dependency.
- Rapzid 2y ago
  The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. If you are blocking the caller you have not "solved" the colored function "problem".
  - Blackthorn 2y ago
    You can build promises with fibers too if you just want to use the value you'd "await" on later on in execution, it's trivial.
  - masklinn 2y ago
    > The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. That is an end not a mean. Again in my experience the vast majority of devs could not give less of a shit about “not blocking the caller” by default. What most devs want is a reasonably cheap way to get a high amount of concurrency. If anything not blocking the caller by default is generally an error, because somebody forgot an await. > If you are blocking the caller you have not "solved" the colored function "problem". Of course you have: you have solved the actual problem that needs solving without using function colouring. That’s how e.g. Go works. Go has problems up the ass but it doesn’t have that one at least. Java is also moving back to Userland threads rather than towards async/await.
    - Rapzid 2y ago
      And it looks pretty much exactly like using threads, which is why they are working so hard on structured concurrency. Go has NOT solved the problem in a fungible way, as evidence by all the dual APIs; methods that return a channel, and those that don't. CSP is great at modeling data flow, but IMHO it's lesser than async/await imperative programing for modeling more standard business logic flows.
mdavidn 2y ago
By default, File.read does block, yes. As it crosses into libc, it releases Ruby's interpreter lock, allowing another Ruby thread to execute while it blocks. Ruby 1.9 added Fibers. These are coroutines with their own call stack that yield and resume explicitly. They're like Goroutines but without Go's scheduler. Fibers are commonly used to build Enumerators, internal iterators support external iteration. File.read in a Fiber still blocks by default. Ruby 3.0 added support for truly asynchronous File.read. The batteries are not included. A fiber scheduler is required to enable this optional feature: https://docs.ruby-lang.org/en/3.3/Fiber.html#class-Fiber-label-Non-blocking+Fibers https://docs.ruby-lang.org/en/3.3/Fiber.html#class-Fiber-lab... https://brunosutic.com/blog/ruby-fiber-scheduler https://brunosutic.com/blog/ruby-fiber-scheduler
jerf 2y ago
You have to watch your definition of "blocking". Node, well, I won't say it created the definition of "blocking" that means "it blocks your entire OS process regardless of how many other things you're trying to do concurrently", but it certainly popularized it, and a lot of people sloppily project the negative aspects of that into threaded languages. In a threaded language, yes, you block on a .Read call until it is complete in that thread, but you don't block the whole OS process; other threads can and do continue on.

by fny 2y ago

masklinn 2y ago

> Aren't all these calls blocking? Only locally, which is pretty much the same as when you `await` a call. > Threading vs an event loop are two different concurrency models. The point is that you can build a "threading" (blocking) model on top of an event loop, such that you get a more natural coding style with most of the gain in concurrency. It loses some, because you only have concurrency between tasks (~threads) leaving aside builtins which might get special cased, but my observation has been that the vast majority of developers don't grok or want to use generalised sub-task concurrency anyway, and are quite confused when that's being done. For instance in my Javascript experience the average developer just `awaits` things as they get them, the use of concurrent composition (e.g. Promise.all) is an exception which you might get into as an optimisation, e.g. `await`-ing in the middle of a loop is embarrassingly common even when the iterations have no dependency.

Rapzid 2y ago
The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. If you are blocking the caller you have not "solved" the colored function "problem".
- Blackthorn 2y ago
  You can build promises with fibers too if you just want to use the value you'd "await" on later on in execution, it's trivial.
- masklinn 2y ago
  > The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point. That is an end not a mean. Again in my experience the vast majority of devs could not give less of a shit about “not blocking the caller” by default. What most devs want is a reasonably cheap way to get a high amount of concurrency. If anything not blocking the caller by default is generally an error, because somebody forgot an await. > If you are blocking the caller you have not "solved" the colored function "problem". Of course you have: you have solved the actual problem that needs solving without using function colouring. That’s how e.g. Go works. Go has problems up the ass but it doesn’t have that one at least. Java is also moving back to Userland threads rather than towards async/await.
  - Rapzid 2y ago
    And it looks pretty much exactly like using threads, which is why they are working so hard on structured concurrency. Go has NOT solved the problem in a fungible way, as evidence by all the dual APIs; methods that return a channel, and those that don't. CSP is great at modeling data flow, but IMHO it's lesser than async/await imperative programing for modeling more standard business logic flows.

mdavidn 2y ago

By default, File.read does block, yes. As it crosses into libc, it releases Ruby's interpreter lock, allowing another Ruby thread to execute while it blocks. Ruby 1.9 added Fibers. These are coroutines with their own call stack that yield and resume explicitly. They're like Goroutines but without Go's scheduler. Fibers are commonly used to build Enumerators, internal iterators support external iteration. File.read in a Fiber still blocks by default. Ruby 3.0 added support for truly asynchronous File.read. The batteries are not included. A fiber scheduler is required to enable this optional feature: https://docs.ruby-lang.org/en/3.3/Fiber.html#class-Fiber-label-Non-blocking+Fibers https://docs.ruby-lang.org/en/3.3/Fiber.html#class-Fiber-lab... https://brunosutic.com/blog/ruby-fiber-scheduler https://brunosutic.com/blog/ruby-fiber-scheduler

jerf 2y ago

You have to watch your definition of "blocking". Node, well, I won't say it created the definition of "blocking" that means "it blocks your entire OS process regardless of how many other things you're trying to do concurrently", but it certainly popularized it, and a lot of people sloppily project the negative aspects of that into threaded languages. In a threaded language, yes, you block on a .Read call until it is complete in that thread, but you don't block the whole OS process; other threads can and do continue on.