News for hackers. Stuff that matters.

A comment on How to think about `async`/`await` in Rust. Parent comment

Re:How to think about `async`/`await` in Rust by sa46 on Wednesday July 05, 2023 @01:22PM (#36603659)
I thought the primary purpose of web workers was that the browser can run the workers in parallel to the main thread. As the spec says:

> [Web workers] allow long tasks to be executed without yielding to keep the page responsive

[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by orangepurple on Wednesday July 05, 2023 @03:06PM (#36605492)
The workers don't block painting and they do not run in a separate process. That's why it's concurrent but not parallel. The web worker does work whenever the main thread is not painting and there is a free time slot. The browser is not painting all the time.

You don't get extra calculation performance with web workers. You just create the illusion of a smooth experience because you don't block painting. It does not complete faster.

[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by sa46 on Wednesday July 05, 2023 @06:31PM (#36608121)
Threads can certainly run in parallel with one another if the OS schedules them on different cores. I did a quick experiment and the main thread and worker threads run in parallel.

https://github.com/jschaf/web-worker-experiment/

> You don't get extra calculation performance with web workers

The primary purpose of web workers is extra calculation performance. From MDN:

> Workers are mainly useful for allowing your code to perform processor-intensive calculations without blocking the user interface thread

[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by orangepurple on Wednesday July 05, 2023 @06:44PM (#36608259)
I should clarify that you can't get extra calculation performance which easily scales with core count due to the gotchas around threading that you mentioned.
[ Parent | on HN ]