You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello folks,
I'm currently working on a visualisation / developper tools experiment to help tackle the issues of time / memory multiplexing in long-running JS apps (Node HTTP servers, web apps, native apps programmed in JS). I'm by no means an expert in systems, scheduling or JS spec/engines, but I've encountered very tedious related bugs in production and this is me trying to prevent them.
I've done some work based upon the new async_hooks API, which raises interesting questions and has led me to think that what I need is a primitive to handle continuation with context between async stack frames scheduled using the host environment I/O APIs (eg. fs.readFile, window.requestAnimationFrame), host event loop scheduling APIs (http.createServer, window.addEventListener), and JS scheduling APIs (eg. new Promise, async/await).
Such a primitive would allow us to build more advanced multiplexing primitives (eg. coroutines, algebraic effects, actors...).
I believe that async_hooks allows us to do something very close to this in Node, and that zones.js has done an amazing work around the same ideas.
My current prototype is very crude and I think that async_hooks allows us to detect/visualize issues but not to prevent them at runtime. However, this alone could help us catch bugs in dev/test phase and certainly be an improvement from the current situation. Signaling a bug is not preventing it but at least it doesn't creep until it blows in your face the way leaking Promises/requestAnimationFrame do.
Would it make sense to work on a base implementation/polyfill that would expose similar low-level primitives both in Node (using async_hooks) and in the browser (using globals monkey-patching)? Could zones.js be implemented in terms of such a primitive? Could the monkey-patching part of zones.js be used as part of the implementation?
The text was updated successfully, but these errors were encountered:
zone.js can work in Browser and node.js, it has some overhead but can do more, preventing and error handling.
async_hooks can just receive notification, it may have better performance. so in the PR above, we trying to make zone.js working in two mode, either interceptor(current zone.js mode) mode or subscription(async_hooks) mode.
but currently there are some issues about the API provided by async_hooks about Promise , so I am not sure when the PR will be finished, if you have some other ideas, please tell me!
Your proposal only helps node.js. Angular is primarily focused on browser. With the upcoming async/await feature, there is no good way for zone.js to monkey patch it. This leads us to come up with zoneless alternative solution for Angular in the future. All of the above leads us to conclude that we don't want to invest more time into this. (Will not fix)
Hello folks,
I'm currently working on a visualisation / developper tools experiment to help tackle the issues of time / memory multiplexing in long-running JS apps (Node HTTP servers, web apps, native apps programmed in JS). I'm by no means an expert in systems, scheduling or JS spec/engines, but I've encountered very tedious related bugs in production and this is me trying to prevent them.
I've done some work based upon the new
async_hooks
API, which raises interesting questions and has led me to think that what I need is a primitive to handle continuation with context between async stack frames scheduled using the host environment I/O APIs (eg.fs.readFile
,window.requestAnimationFrame
), host event loop scheduling APIs (http.createServer
,window.addEventListener
), and JS scheduling APIs (eg.new Promise
,async/await
).Such a primitive would allow us to build more advanced multiplexing primitives (eg. coroutines, algebraic effects, actors...).
I believe that
async_hooks
allows us to do something very close to this in Node, and thatzones.js
has done an amazing work around the same ideas.My current prototype is very crude and I think that
async_hooks
allows us to detect/visualize issues but not to prevent them at runtime. However, this alone could help us catch bugs in dev/test phase and certainly be an improvement from the current situation. Signaling a bug is not preventing it but at least it doesn't creep until it blows in your face the way leaking Promises/requestAnimationFrame do.Would it make sense to work on a base implementation/polyfill that would expose similar low-level primitives both in Node (using
async_hooks
) and in the browser (using globals monkey-patching)? Couldzones.js
be implemented in terms of such a primitive? Could the monkey-patching part ofzones.js
be used as part of the implementation?The text was updated successfully, but these errors were encountered: