- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Mar 2009 15:27:41 -0700
On Mon, Mar 23, 2009 at 2:45 PM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 24 Mar 2009, Robert O'Callahan wrote: >> >> I think a better construct might be some sort of "yield" which >> explicitly returns to a (nested) browser event loop and basically acts >> as a script completion point. Even browsers that only use a single >> thread can run the event loop there so that testing in those browsers >> will reveal bugs. > > On Mon, 23 Mar 2009, Jeremy Orlow wrote: >> >> I really like the idea of some generic yield, though I wonder if there's >> some reason it hasn't been added earlier. ?People have been using the >> setTimeout(..., 0) trick for a while to get around slow script warnings >> (and general unresponsiveness)...so surely something like this must have >> come up before? ?If so, what were the drawbacks? > > The obvious problem is that a naive implementation could easily end up > with a stack overflow, if it didn't pop the current script off the stack > and use the "real" event loop each time. > > I would be very happy to add a "navigator.yield()" method that basically > causes the current script to be turned into a continuation and requeued on > the event loop. It would make a lot of scripts a lot easier. I imagine the > implementation burden would be pretty high though. Indeed it would. We've had lots of issues around synchronous XMLHttpRequest, which in firefox is implemented internally using a yield-like construct. And it'd probably be many times worse with an API that is specifically encouraged to be used, and thus presumably will get used a lot. Unlike sync XMLHttpRequest which is actively discouraged. And that's not even touching on the stack space limitations that you're quite likely to run in to when you have an API specifically for nesting. / Jonas
Received on Monday, 23 March 2009 15:27:41 UTC