First-class Multi-threading support
kizer at kizer.com.ng
Fri Apr 26 08:22:38 UTC 2019
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
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.
On Thu, 25 Apr 2019 at 21:03, Ranando King <kingmph at gmail.com> wrote:
> 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.
> On Thu, Apr 25, 2019 at 1:41 PM Chinenye Onuegbu <kizer at kizer.com.ng>
>> avoided, even though there is a strong case for real multi-threading
>> 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
>> link to the gist:
>> 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.
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss