425988 - Add coroutine support as used in the synchronous XMLHttpRequest implementation

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Kris Zyp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

The new behavior exhibited by synchronous mode XMLHttpRequest belies an internal coroutine mechanism in Firefox. It is observable that synchronous XHR suspends execution of a call stack, and allows other events to be executed. When the response is received, the suspended call stack is resumed. This is to fix bug 403535 (and allowing other events to take place during suspension has been erroneously been reported as bugs 340345 and 412418).
I would like to see this suspension/coroutine capability exposed as a JavaScript API. While XHR is the biggest use case for coroutines in JavaScript, there are certainly other valuable applications, most notably writing animations and flow-based wizards, that could benefit tremendously from a coroutine API, rather than having to resort to complicated callbacks/CPS. Here is a suggested API:
constructor: mozilla.Future
methods:
fulfill(result)
suspend()

Therefore, to emulate FF3's synchronous XHR behavior with async XHR:
var xhr = new XMLHttpRequest
xhr.open("GET","resource",true);
var future = new mozilla.Future;
xhr.onload = function() {
 future.fulfill(); // fulfill the future and resume execution when onload is called
}
xhr.send(...);
future.suspend(); // suspend until the response is received


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



I would be glad to enumerate other use cases if greater motivation is needed.

Comment 1

[Brian Crowder]

Isn't this just the sort of thing generators are for?  Perhaps I'm not totally clear on what you want, Kris.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that the mechanism used by XMLHttpRequest is very heavyweight and has finite stacking depth limited by the size of your C stack.  That is, if you nested a bunch of sync XMLHttpRequests off each others event processing you could quickly cause resource exhaustion slowdown.

You really don't want to be using this method for JS animations, trust me.

Like Brian said, generators seem to be much more what you want for the things you're talking about.

Comment 3

[Kris Zyp]

Generators don't cut it, they are only one deep coroutines, they can't suspend the entire stack and provide implementation encapsulation of asynchronous processing.

Comment 4

[Boris Zbarsky [:bzbarsky]]

generators can encapsulate arbitrary state.  You're correct that you have to provide the asynchronous part (using say setTimeout).

Note that this way you have some control over how much state you're carrying around (or leaking, as the case may be); with the coroutine approach as you describe it it would be trivial to leak everything your page ever did for the lifetime of the page (because it would all be suspended waiting on something else).

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #3)
> Generators don't cut it, they are only one deep coroutines, they can't suspend
> the entire stack and provide implementation encapsulation of asynchronous
> processing.

Coroutines break encapsulation too, suspending arbitrary code that may not be prepared to lose its invariants. Why make them out to be an unmixed good?

/be

Comment 6

[Kris Zyp]

I understand the costs that abstractions might hide and the risks of full stack coroutines. I am simply observing that FF has already opened this can of worms with the new sync XHR handling, and suggesting that if this functionality already exists, why not let devs utilize it with a direct API instead of limiting it to XHR calls? XHR call stacks are no different than call stacks with a different async action at the top. 

Comment 7

[Boris Zbarsky [:bzbarsky]]

We, and others, consider it a bug that events are delivered to the page during sync XHR, for what it's worth.

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Yes, it violates the run-to-completion model of JavaScript, which is a pretty bad bug. 

Comment 9

[Kris Zyp]

From what I understand you guys (Mozilla) have put significant effort into adding this feature, the opposition to it is amusing ;). Anyway, I understand the principles this feature violates, but FWIW, I find the UI experience and capabilities derived from it far outweigh the costs.

Comment 10

[Boris Zbarsky [:bzbarsky]]

The feature we want is for the browser UI to not freeze while a sync XHR is in progress.

The bug we do not want is for webpage code to be reentered while a sync XHR is in progress.

Comment 11

[Thomas Wisniewski]

Closing this on the presumption that this feature request is obsolete, given that we now have async/await, Promises, generators and so forth in modern JS.