Discuss
  • Feature Request

Feature Request

# Robert Parham (5 years ago)

Are there any threading proposals? If not, would anyone be interested in creating one?

Webworkers are great, but require separate files that just aren't always convenient to maintain. I've created this wrapper for webworkers that allows users to create in-line disposable threads, somewhat similar to threads in Java.

gist.github.com/Pamblam/683d5ae429448adfa6d6e7fb30de39b2

If we could get something similar implemented natively that would be very cool.

Robert "Gordie" Parham pamblam.com 813.616.0819

[ad.png]

# guest271314 (5 years ago)

Chromium has implemented TaskWorklet

Polyfill

Threading and Tasks in Chrome

Worklets

The Worklet interface is a lightweight version of Web Workers and gives developers access to low-level parts of the rendering pipeline. With Worklets, you can run JavaScript and WebAssembly code to do graphics rendering or audio processing where high performance is required.

The following techniques are used in order to encourage authors to write code in an idempotent way:

  • No reference to the global object, e.g. self on a DedicatedWorkerGlobalScope.

  • Code is loaded as a module script [html.spec.whatwg.org/multipage/webappapis.html#module-script] which resulting in the code being executed in strict mode code without a shared this. This prevents two different module scripts sharing state by referencing shared objects on the global scope.

  • These specifications must require user agents to always have at least two WorkletGlobalScopes per Worklet and randomly assign a method or set of methods on a class to a particular global scope. These specifications can provide an opt-out under memory constraints.

  • User agents can create and destroy WorkletGlobalScopes at any time for these specifications.

# guest271314 (5 years ago)

Evidently TaskWorklet is no longer implemented by Chromium bugs.chromium.org/p/chromium/issues/detail?id=879306. Though TaskQueue (ScriptedTaskQueue) chromium.googlesource.com/chromium/src/+/64f633432afef4a8779b45229eb3b7a060222bb0 is still defined at window.

    (async() => {
      const queue = window.TaskQueue.default("best-effort");
      let result = void 0;
      await queue.postTask(function() { result = "task1" });
      console.log(result);
    })();

See also WICG/main-thread-scheduling/blob/master/README.md#i

# Isiah Meadows (5 years ago)

I've weakly suggested this in the past (sorry, buried in old list discussions and IRC), but I haven't come up with something that 1. doesn't have nearly the overhead of web workers, and 2. doesn't have nearly the footguns of C's direct thread-based model that's mostly emulated by practically every remotely major software programming language not using CSP or actors/processes. The first is difficult to avoid without avoiding message passing altogether, hence why SharedArrayBuffer appeared in the first place. The second is difficult to avoid if you want to minimize message passing overhead, especially without immutable objects (which can usually be sent without copy between threads of the same parent process).

Given Erlang's parallel programming model has proven itself to stand the test of time (it's hardly changed since the 80s) and that others (such as Ruby and some Java circles) are planning to adapt it, I feel it might be worth waiting for this stage-0 proposal to make it in in some form or another first, then pushing for language-level support of parallelism: rricard/proposal-const-value-types

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com