Quantcast

Using microtask checkpoints for resetting the slow script dialog timer

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using microtask checkpoints for resetting the slow script dialog timer

Boris Zbarsky
Right now we use the ScriptEvaluated call to reset the "time we have
been running script" state.  This requires us to have hacks for modal
state in there, and still has problems if we bounce in and out of
scripts (like event listeners, say) each of which is quick but which
cumulatively take lots of time.

Would it make any sense to reset the timer off a microtask checkpoint
instead?  So conceptually we'd do it like so:

1)  A call to the operation callback records the current time if we're
     in the "reset" state.
2)  Following calls compare the "now" time to the recorded time and put
     up the slow script dialog as needed.
3)  Clicking "stop script" disables script on the page (so if this
     happens inside an event listener, that will not run any more script
     for that event dispatch).
4)  A microtask checkpoint resets our state and reenables script if it
     was disabled due to item 3.  Probably after doing the mutation
     handlers and whatnot.

Thoughts?

-Boris
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Bobby Holley-2
Yeah, ScriptEvaluated is totally wonky and needs to go away.

I've always been really wary of microtasks though - it seems like one of
those magic things that we sprinkle everywhere (like requests and unmarking
gray) that we're generally moving away from.

What about tying it to script entry points? Are they roughly isomorphic, or
are there important divergences?

bholley
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 7/10/13 5:09 PM, Bobby Holley wrote:
> I've always been really wary of microtasks though - it seems like one of
> those magic things that we sprinkle everywhere (like requests and unmarking
> gray) that we're generally moving away from.

Microtasks are clearly defined in the spec, is the idea, so we shouldn't
have any issues in terms of where microtask checkpoints happen.

Basically there are two places they happen: when the JS stack completely
unwinds and when the event loop spins.

> What about tying it to script entry points? Are they roughly isomorphic, or
> are there important divergences?

There are important divergences.  If I do a dispatchEvent, there is a
script entry point for each event listener that fires, but we don't
really want to be resetting the slow script timer each time an event
listener completes, I believe.  That's basically the setup we have right
now and one I'd like to move away from.

-Boris

_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Bobby Holley-2
On Wed, Jul 10, 2013 at 2:16 PM, Boris Zbarsky <[hidden email]> wrote:

> Microtasks are clearly defined in the spec, is the idea, so we shouldn't
> have any issues in terms of where microtask checkpoints happen.
>
> Basically there are two places they happen: when the JS stack completely
> unwinds and when the event loop spins.


Ok. They seem pretty wack-a-mole in Gecko, though.

There are important divergences.  If I do a dispatchEvent, there is a
> script entry point for each event listener that fires, but we don't really
> want to be resetting the slow script timer each time an event listener
> completes, I believe.  That's basically the setup we have right now and one
> I'd like to move away from.


But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
us to the same problem? Or is the idea that the 'checkpoint' only happens
when the microtask depth hits zero? If so, how do we handle nested event
loops?

bholley
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 7/11/13 1:15 AM, Bobby Holley wrote:
> Ok. They seem pretty wack-a-mole in Gecko, though.

To the extent that the concept of "unwind the stack" is a bit
whack-a-mole, yeah.  I'm not saying it couldn't be better.  ;)

> But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
> us to the same problem? Or is the idea that the 'checkpoint' only happens
> when the microtask depth hits zero?

Yes, exactly.

> If so, how do we handle nested event loops?

By doing a checkpoint when the event loop spins, like the spec requires.
  See nsXPConnect::AfterProcessNextEvent.  Note that the only thing we
do off a microtask checkpoint right now is
nsDOMMutationObserver::HandleMutations.

-Boris
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Bobby Holley-2
On Wed, Jul 10, 2013 at 10:36 PM, Boris Zbarsky <[hidden email]> wrote:

> To the extent that the concept of "unwind the stack" is a bit
> whack-a-mole, yeah.  I'm not saying it couldn't be better.  ;)


Ok. Could we make this better by tying it to the 0<->1 transition in
request depth on the runtime? That should more or less correspond with the
first cx we push, which should give us a much more reliable answer.


> But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
> us to the same problem? Or is the idea that the 'checkpoint' only happens
> when the microtask depth hits zero?
>

Yes, exactly.


What are the situations where the stack completely unwinds but we don't
spin the top-level event loop?

bholley
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 7/11/13 1:43 AM, Bobby Holley wrote:
> Ok. Could we make this better by tying it to the 0<->1 transition in
> request depth on the runtime? That should more or less correspond with the
> first cx we push, which should give us a much more reliable answer.

I'm not sure we can; microtasks might need to span execution with no JS
on the stack.  Olli would know for sure...

> What are the situations where the stack completely unwinds but we don't
> spin the top-level event loop?

For us right now, or in general?

Here's an example: it's not clear to whether a refresh driver tick
should have one microtask around all the requestAnimationFrame callbacks
or not.  Right now we do not, but maybe we should.

But more to the point, exactly what constitutes a microtask will be
specced, and seems to align well with how the slow script dialog should
work, to me.

-Boris
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

Boris Zbarsky
On 7/11/13 2:04 AM, Boris Zbarsky wrote:
> But more to the point, exactly what constitutes a microtask will be
> specced, and seems to align well with how the slow script dialog should
> work, to me.

Hmm...  Though I suppose it's possible that the spec could define on
microtask per requestAnimationFrame callback while we want to have the
slow-script timer consider all the callbacks for a single refresh driver
tick together...

I guess the other problem is to just reset the slow script state when we
spin the event loop.  That should help with the real problem we're
trying to solve, which is being away from the event loop for too long,
right?

-Boris
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using microtask checkpoints for resetting the slow script dialog timer

SmauG-2
In reply to this post by Boris Zbarsky
On 07/11/2013 01:43 AM, Bobby Holley wrote:

> On Wed, Jul 10, 2013 at 10:36 PM, Boris Zbarsky <[hidden email]> wrote:
>
>> To the extent that the concept of "unwind the stack" is a bit
>> whack-a-mole, yeah.  I'm not saying it couldn't be better.  ;)
>
>
> Ok. Could we make this better by tying it to the 0<->1 transition in
> request depth on the runtime? That should more or less correspond with the
> first cx we push, which should give us a much more reliable answer.
>
>
>> But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
>> us to the same problem? Or is the idea that the 'checkpoint' only happens
>> when the microtask depth hits zero?
>>
>
> Yes, exactly.
>
>
> What are the situations where the stack completely unwinds but we don't
> spin the top-level event loop?

Event handling. If you have several event listeners, microtask check point is after each of those.

>
> bholley
>

_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Loading...