Currently CallbackObjects and their child classes can only either capture a stack during creation and set it as the async parent stack during execution, or not set an async parent stack at all. This means they can't be used in situations where we want the code executed by running the callback to have a different async stack. With an additional ctor overload that takes a saved frame object to be used as the parent stack, that can be solved. Patch coming up.

This patch lets me set a Promise's allocation stack as the async parent stack for promise job callbacks, which is what the current implementation does. I.e., it allows us to keep exactly the same results we have right now.

Comment on attachment 8730998 [details] [diff] [review] Add support for supplying preexisting stack instead of capturing one for use as the async parent stack of CallbackObject Review of attachment 8730998 [details] [diff] [review]: ----------------------------------------------------------------- Looks reasonable to me. Note that I'm not a peer in this area. Also before landing I think it would be good to verify that the intended use gives the result we want. I think the idea is to use the stack at "new Promise"-time when invoking the ".then" callback? If so then I'm still not sure that this is desirable.

Comment on attachment 8730998 [details] [diff] [review] Add support for supplying preexisting stack instead of capturing one for use as the async parent stack of CallbackObject r=me

https://hg.mozilla.org/integration/mozilla-inbound/rev/4fa1ec3b5d4d906b33d27563735861db1da1b6b6 Bug 1257030 - Add support for supplying preexisting stack instead of capturing one for use as the async parent stack of CallbackObject. r=bz,tromey