LGTM.
http://gwt-code-reviews.appspot.com/77810/diff/34/1016 File user/src/com/google/gwt/core/client/impl/Impl.java (right): http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode163 Line 163: if (hasEntered) { On 2009/10/13 19:26:24, bobv wrote: > When we did the emulated JS stack trace work, we decided to treat the reentrancy > situation as though it were one big stack. I think the same thing applies here. > You might really, really hope that you're code doesn't hit a reentrancy > situation, but we really can't mask what the browser is actually doing. If you > really care about masking it, that could be done at a higher-level API. > Re: FinallyCommand, the way Joel and I have been defining it, it's spec'ed to > execute after all use code, but just before we release back to the browser's > event queue. In my mind, that means that FinallyCommands enqueued in reentrant > case execute in the same batch as those enqueued in the outermost execution > context. > @Joel, will you be the decider? What's going to make the most sense (if > anything makes sense at all anymore)? Ah'm tha deecider today, yay! Seriously, I think the "one big stack" view of js reentrancy makes the most sense. It's almost definitely what's actually happening in most (all?) browsers in practice, and as you point out, it doesn't really matter much if a few FinallyCommands get executed slightly later under obscure circumstances. I expect this will pretty much never happen in practice anyway. http://gwt-code-reviews.appspot.com/77810 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
