1241961 - When the main thread pauses, all workers should be paused as well.

Status: RESOLVED WONTFIX

(DevTools :: Debugger, enhancement, P3)

Description

[Eddy Bruel [:ejpbruel]]

In debuggers such as GDB and LLDB, the default behaviour is for all threads to pause if a single thread pauses. Since this is what people are used to, I feel that this is what we should implement for our debugger as well.

Comment 1

[Brian Grinstead [:bgrins]]

(In reply to Eddy Bruel [:ejpbruel] from comment #0)
> In debuggers such as GDB and LLDB, the default behaviour is for all threads
> to pause if a single thread pauses. Since this is what people are used to, I
> feel that this is what we should implement for our debugger as well.

On the other hand, Chrome DevTools allows pausing a worker without pausing the main thread.  So that's probably closer to what our audience is used to.  I prefer this behavior.. imagine if a service worker is paused - in this case do we also pause all tabs that it's controlling?  Also, being able to pause a web worker lets you simulate situations where a task is really long running by setting a breakpoint, not resuming immediately, and then testing how your page reacts.

Comment 2

[Eddy Bruel [:ejpbruel]]

(In reply to Brian Grinstead [:bgrins] from comment #1)
> (In reply to Eddy Bruel [:ejpbruel] from comment #0)
> > In debuggers such as GDB and LLDB, the default behaviour is for all threads
> > to pause if a single thread pauses. Since this is what people are used to, I
> > feel that this is what we should implement for our debugger as well.
> 
> On the other hand, Chrome DevTools allows pausing a worker without pausing
> the main thread.  So that's probably closer to what our audience is used to.
> I prefer this behavior.. imagine if a service worker is paused - in this
> case do we also pause all tabs that it's controlling?  Also, being able to
> pause a web worker lets you simulate situations where a task is really long
> running by setting a breakpoint, not resuming immediately, and then testing
> how your page reacts.

I would argue that for page workers, pausing all threads should be the default, but we should still allow for the possibility of pausing a single worker at a time.

Service workers are somewhat of a special case, because they don't really live inside the page that they are controlling. I think of them more as background processes that intercept network requests from certain pages. Here, it might make more sense to only pause the service worker by default.

Does that sounds reasonable to you?

Comment 3

[Brian Grinstead [:bgrins]]

(In reply to Eddy Bruel [:ejpbruel] from comment #2)
> (In reply to Brian Grinstead [:bgrins] from comment #1)
> > (In reply to Eddy Bruel [:ejpbruel] from comment #0)
> > > In debuggers such as GDB and LLDB, the default behaviour is for all threads
> > > to pause if a single thread pauses. Since this is what people are used to, I
> > > feel that this is what we should implement for our debugger as well.
> > 
> > On the other hand, Chrome DevTools allows pausing a worker without pausing
> > the main thread.  So that's probably closer to what our audience is used to.
> > I prefer this behavior.. imagine if a service worker is paused - in this
> > case do we also pause all tabs that it's controlling?  Also, being able to
> > pause a web worker lets you simulate situations where a task is really long
> > running by setting a breakpoint, not resuming immediately, and then testing
> > how your page reacts.
> 
> I would argue that for page workers, pausing all threads should be the
> default, but we should still allow for the possibility of pausing a single
> worker at a time.

From what I understand both 'modes' have their own set of implementation challenges, so if we support both it'll be extra work upfront and more code to maintain, right?  Is one much harder than the other to implement?

Potch and Dan, do you have opinions about the 'pause' behavior for workers on a page when debugging web workers?  I believe in Chrome, pausing a worker pauses just that thread (other workers and the main thread keep running), whereas with GDB pausing a thread also pauses the whole process (and vice versa).  Do you find it useful to be able to pause an individual worker and still interact with the page, or would it be easier to reason about things / work with the debugger if the whole world paused once a worker did?  Or does it not matter either way?

> Service workers are somewhat of a special case, because they don't really
> live inside the page that they are controlling. I think of them more as
> background processes that intercept network requests from certain pages.
> Here, it might make more sense to only pause the service worker by default.

Sure, makes sense

Comment 4

[Potch [:potch]]

It's fairly a toss-up, but I'd lean toward matching other browsers' behavior vs matching GDB. Web developers are more likely to be trying to use multiple browsers for testing than using GDB, so cross-browser consistency is important.

Comment 5

[Dan Callahan [:callahad]]

I don't have a strong preference. My gut feeling is that pausing the world feels better to me.

In most cases, I imagine myself wanting to either look at the worker completely in isolation, or follow messages from the page, into the worker, and back out to the page. Stopping the world sounds like an easier way to follow those.

Comment 6

[Brian Grinstead [:bgrins]]

One more thing to consider about a pause in the worker also pausing the main thread is that we might end up paused in main thread but not at a line.  This is similar to what used to happen when you pressed the 'pause' button in the debugger, but we switched it to instead be 'pause on next script execution' intentionally in Bug 789430 because it was more useful and IIRC it also prevented some bugs where the debugger was expecting we'd be paused on a line.

Comment 7

[Eddy Bruel [:ejpbruel]]

(In reply to (Unavailable until Apr 6) Brian Grinstead [:bgrins] from comment #6)
> One more thing to consider about a pause in the worker also pausing the main
> thread is that we might end up paused in main thread but not at a line. 
> This is similar to what used to happen when you pressed the 'pause' button
> in the debugger, but we switched it to instead be 'pause on next script
> execution' intentionally in Bug 789430 because it was more useful and IIRC
> it also prevented some bugs where the debugger was expecting we'd be paused
> on a line.

Oh I see, so the problem is that we could end up pausing the main thread while it is in the event loop (i.e. not running any user code)? That's something we need to consider, yeah.

Comment 8

[Jason Laster [:jlast]]

My personal belief is that chrome's strategy of pausing a single thread is okay.

I'm going to de-prioritize this as there is plenty of other worker related work this quarter.

Comment 9

[Jason Laster [:jlast]]

Closing as we'v discussed the UX and decided that each thread should behave independently.