• ☆ Yσɠƚԋσʂ ☆OP
    link
    fedilink
    arrow-up
    2
    arrow-down
    10
    ·
    1 year ago

    I literally just explained this to you in a prior comment. Let’s say you have a web server that’s accepting connections. You have one thread that grabs the connection and spawns a thread from a pool of workers threads to handle it. Then it goes back to listening for connections. This is how things work on platforms like the JVM. The runtime manages the execution of the threads. This is similar to the way the OS handles scheduling processes. When you’d doing async by hand you’re basically handrolling your own scheduler each time.

    What stops you from using worker threads is lack of ergonomics. Just the fact that each worker has to live in a separate file creates friction. In a sane language you can just do new Thread().start() and you’re done. In Js it’s a Rube Goldberg machine as always. When you look at at actual code people write in Js, you see async code everywhere. So, maybe you can answer why you think that is, and why people aren’t using worker threads to write sync style code they’d write in other languages.

      • ☆ Yσɠƚԋσʂ ☆OP
        link
        fedilink
        arrow-up
        2
        arrow-down
        10
        ·
        1 year ago

        I’ve directly addressed your points, and I get the impression that you’re the one who’s ignoring my points here. The reality is that blocking operations in js are handled using async calls, and reasoning about async code is inherently more difficult than sync code. Platforms that provide proper threading allow developers to write sync style code and handle blocking by using threads that are managed by the runtime. While you have workers in Js, it’s pretty clear that they’re not meant to be used in the same way, nor do people use them this way in practice.