First-class Multi-threading support
kingmph at gmail.com
Thu Apr 25 19:03:05 UTC 2019
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> wrote:
> 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 add
> 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