The work has since moved into the specification that defines the event loop, i.e. the HTML Standard:
* https://github.com/whatwg/html/issues/512 * https://github.com/whatwg/html/pull/2789 From: es-discuss [mailto:[email protected]] On Behalf Of Isiah Meadows Sent: Tuesday, June 27, 2017 16:25 To: Calvin Metcalf <[email protected]>; C. Scott Ananian <[email protected]> Cc: [email protected] Subject: Re: Microtask scheduling I was browsing and stumbled on a strawman that is nearly identical to what I proposed here (mod the extra args handling), just a couple years old: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#510-globalasap-for-enqueuing-a-microtask On Mon, Jun 26, 2017, 13:49 Calvin Metcalf <[email protected]<mailto:[email protected]>> wrote: One of the big use cases for process.nextTick is throwing errors outside the current stack, either to avoid preventing cleanup or to avoid being caught in try/catch blocks or promise chains so using a promise directly isn't very useful. This came up in the browserify/webpack shim for process.nextTick On Mon, Jun 26, 2017 at 12:29 PM C. Scott Ananian <[email protected]<mailto:[email protected]>> wrote: Promise dispatch should actually simplify to this in certain common cases. I meant to write up a document describing the typical dispatch optimizations high-performance Promise libraries do, based on my experiences writing https://github.com/cscott/babybird (although Optimization Notes in the README of that package contains the basic details). Assuming the Promise implementation is fast, then Promise#then0(...) should basically give you direct access to the internal `asap`-like dispatcher. --scott On Mon, Jun 26, 2017 at 8:20 AM, Calvin Metcalf <[email protected]<mailto:[email protected]>> wrote: Kris, you're conflating macrotasks and microtasks [1]. This has come up a couple times before and there have been issues raised by browser venders[2][3]. 1. https://github.com/YuzuJS/setImmediate#macrotasks-and-microtasks 2. https://bugzilla.mozilla.org/show_bug.cgi?id=686201 3. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Hn3GxRLXmR0/XP9xcY_gBPQJ On Mon, Jun 26, 2017 at 2:51 AM Kris Siegel <[email protected]<mailto:[email protected]>> wrote: This seems more like a platform-level feature versus something that needs to be part of the ECMAScript standard. Also, keep in mind it's rarely a good idea to explicitly call nextTick() in node as it executes the code immediately after the current code is finished and before the next, scheduled code (this can cause issues with processing I/O if you're doing it too frequently). In a browser you can sorta emulate similar behavior through IE's setImmediate(), using postMessage() or even the requestAnimationFrame(). Granted none of those are exactly like nextTick() and I wouldn't mind seeing something like setImmediate() become more of a standard but this isn't for the ECMAScript group. On Wed, Jun 21, 2017 at 2:10 PM, Isiah Meadows <[email protected]<mailto:[email protected]>> wrote: It's a relatively low-level operation, but in performance-sensitive async code and polyfills, there's still a strong need for raw microtask scheduling, at a much lower level than promises. In particular, there's two very frequently used modules providing a wrapper for this specific thing: 1. next-tick: A browser polyfill for Node's `process.nextTick`, with over 2M downloads last month and 88 direct dependents. 2. asap: A microtask scheduler that avoids blocking Node's I/O loop, with over 7M downloads last month and 88 direct dependents. In addition, several libraries like Bluebird have to implement their own wrappers to gain similar functionality without assuming another dependency. Any chance something like Node's `process.nextTick` could be added, maybe something like `Promise.schedule(func, thisArg, ...args)`? ----- Isiah Meadows [email protected]<mailto:[email protected]> Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com<http://www.isiahmeadows.com> _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
