Discuss
  • First-class Multi-threading support

First-class Multi-threading support

# Chinenye Onuegbu (5 years ago)

I am not exactly sure why multi-threading support in JavaScript has been avoided, even though there is a strong case for real multi-threading support in JavaScript. This is usually reflected in the race to fit every event callback within 16ms to avoid dropping frames.

To cover for some of these deficiencies, web workers, worker_threads, process.fork, etc have been introduced in the past, all of which are cumbersome to use. I understand that multi-threading is difficult to get right, and it provides a number of challenges including making it easy to create difficult-to-debug bugs, but I am of the opinion that we can at least start a discussion on this.

In light of this, I created a draft of what I think is a "safe" way to add "user-space", first-class multi-threading support in JavaScript. The link to the gist: gist.github.com/xkizer/d63ac72ef48720c2066fbc9d3580ea90

A few things to note:

  1. I am not an expert in multi-threading, and could have made some otherwise obvious wrong assumptions/blunders
  2. I am not an expert in JS engines, and do not know how easy/difficult these are to actually bring to fruition

I am looking for comments and constructive criticisms. Thanks in advance.

Kizer

# Ranando King (5 years ago)

Devil's Advocate time....

What can you get from threading that you can't already get on a single thread? If I subclass Promise, make all of the relevant functions return this customized promise, I can create fairly easy to debug code that behaves as though it is multithreaded. I can even go 1 step further and do this for all of my code and essentially turn each function into a stand-alone fiber. Like this, I can get the benefit of thread-like behavior without the engine having to carry the burden of maintaining thread contexts on top of its own script contexts.

# Chinenye Onuegbu (5 years ago)

There are many ways to do async in JavaScript. JavaScript itself takes a lot of pride in being heavily async-based. However, what is not easy to deal with is time-consuming tasks. To run these without blocking the main thread, you need to find a way to break the task into small pieces and yield control after each piece is finished to give way to other tasks. This is not only adds a lot of overhead, it can also get very complicated very quickly. It also feels like a workaround, and a hack, for something that is standard in a lot of other major languages.

This applies also to fibers. Moreover, fibers is restricted to node.js environment.

There is also requestIdleCallback. One thing all these have in common is that your task must either be fast or divided up into smaller tasks, else you gain nothing (maybe I am wrong here, maybe there is something I am missing). Additionally, none of these take advantage of multi-core CPUs.

# Zang MingJie (5 years ago)

To support multi-thread, there are way more thing to clarify than just a new thread function, here I'll list some of them:

  1. Memory access model. can memory (variable) access be reordered to improve performance ?
  2. dead-lock-free and resource-safe fork-exec. When forking within a multi-threaded process, can the new process avoid acquiring locks (like malloc lock) which hold by other threads ? can the new process correctly close all fd opened be other threads ?
  3. Lock, mutex and conditional variable api.

Take python as an example, the thread support in python is horrible. Everyone will suggest you don't use python threads, you will hit tons of bug, workarounds while using it. When a high-level language is not designed with multi-threaded support at the beginning, it will be nearly impossible to add it later.

On Fri, Apr 26, 2019 at 2:41 AM Chinenye Onuegbu <kizer at kizer.com.ng> wrote:

I am not exactly sure why multi-threading support in JavaScript has been

avoided, even though there is a strong case for real multi-threading support in JavaScript. This is usually reflected in the race to fit every event callback within 16ms to avoid dropping frames.

To cover for some of these deficiencies, web workers, worker_threads,

process.fork, etc have been introduced in the past, all of which are cumbersome to use. I understand that multi-threading is difficult to get right, and it provides a number of challenges including making it easy to create difficult-to-debug bugs, but I am of the opinion that we can at least start a discussion on this.

In light of this, I created a draft of what I think is a "safe" way to

add "user-space", first-class multi-threading support in JavaScript. The link to the gist: gist.github.com/xkizer/d63ac72ef48720c2066fbc9d3580ea90

A few things to note:

  1. I am not an expert in multi-threading, and could have made some

otherwise obvious wrong assumptions/blunders

  1. I am not an expert in JS engines, and do not know how easy/difficult

these are to actually bring to fruition

# guest271314 (5 years ago)

Are you looking for TaskWorklet cs.chromium.org/chromium/src/third_party/blink/renderer/core/workers/experimental/task_worklet_global_scope.idl or WorkerTaskQueue cs.chromium.org/chromium/src/third_party/blink/renderer/core/workers/experimental/worker_task_queue.idl ?

See also