Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Tue, Mar 24, 2009 at 1:17 PM, Jonas Sicking wrote: > On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson wrote: > > On Mon, 23 Mar 2009, Jonas Sicking wrote: > >> > >> 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. > > > > I think any sane implementation of this would have to be non-recursive. > > That's part of why I think it'd be so hard to implement. > > Indeed, that'd be really hard to implement in the generic case. For > example a navigator.yield() inside an event handler, or inside a > callback. > > We'd basically have to redesign all the code that implements the DOM > and all other APIs that are exposed to javascript. > > Or rewrite our code in a language that supports continuations, which > C/C++ doesn't do. (no, setjmp and longjmp doesn't count :) ). > Not necessarily, it depends on the semantics. For example, you might retain the option for "yield" to do nothing (i.e. it offers no liveness guarantees). In that case you would have the option of not yielding in difficult situations like event handlers or callbacks, or if recursion gets too deep. Or a spec could say which script executions allow yielding and which don't. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson wrote: > On Mon, 23 Mar 2009, Jonas Sicking wrote: >> >> 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. > > I think any sane implementation of this would have to be non-recursive. > That's part of why I think it'd be so hard to implement. Indeed, that'd be really hard to implement in the generic case. For example a navigator.yield() inside an event handler, or inside a callback. We'd basically have to redesign all the code that implements the DOM and all other APIs that are exposed to javascript. Or rewrite our code in a language that supports continuations, which C/C++ doesn't do. (no, setjmp and longjmp doesn't count :) ). / Jonas
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, 23 Mar 2009, Jonas Sicking wrote: > > 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. I think any sane implementation of this would have to be non-recursive. That's part of why I think it'd be so hard to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, Mar 23, 2009 at 2:45 PM, Ian Hickson 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
[whatwg] navigator.yield()? (Was: localStorage + worker processes)
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
