What does Google think of async_wrap in the browser?

[Qard]

Part of my efforts with async_wrap are to consolidate async boundary linking between node/io.js and the browser. I'm wondering if the WG participants from Google have any comments/insight/interest to share in the idea of an async_wrap-like thing in the browser.

I'd like to see a standardized interface (in more than just Chrome) to track exits and returns to JavaScript-land from async calls. Is this a thing Google is already thinking about? Implementing? Using internally? Would people even want it in the browser? Is there valuable insight to be had from either Google or the iojs team?

@natduca @ofrobots

[natduca]

Is there some light(heavy?) reading you can point me at to help me understand async wrap better? I got the crash course in the vc a few weeks ago, but it was super high level so I don't think I can quite yet provide feedback one way or another. :)

[Qard]

Roughly, it works something like this:

var kCallInitHook = 0
var asyncHooksObject = {}
async_wrap.setupHooks(asyncHooksObject, function init () {
  // init event handler
}, function before () {
  // before event handler
}, function after () {
  // after event handler
})
// Turn above hooks on by setting `kCallInitHook` to 1
asyncHooksObject[kCallInitHook] = 1

// init triggers on call
fs.readFile(file, function (err, res) {
  // before triggers before running callback

  // stuff happens in callback

  // after triggers after running callback
})

Inside the init, before and after functions, you have a shared context object that you can use to associate the entry into a JS callback to the originating call. It could be useful for generating long stack-traces, automatic tracing, or more complicated things like continuation-local-storage.

Now, the first two can mostly be achieved through something like trace_event. Implementing something like continuation-local-storage, however, requires active interaction with the code being traced. This is super useful for things like tracing user behaviour. Currently this requires huge, ugly hacks like zone.js to monkey-patch the world. Even if you are only interested in a couple particular things, you still have to patch everything because the event loop will jump between tasks and you will lose track of the last relevant parent call to find your context object.

What I am hoping for is for browsers to adopt a similar concept to async_wrap, such that one could at least have an id assigned to each synchronous context and have all callbacks link back to their appropriate parent context somehow. That way the call tree could be traversed to find the last relevant parent id and link directly to that without needing to care about any of the things that happened between the two.

[joshgav]

closing old AsyncWrap issues, please start a new thread if appropriate