This sounds right to me. Isn't this pretty much a ScriptThread? There are a lot of different ways to present the big picture. Sometimes you want workers to stop and be paused along with the main thread; at other times, you'd like the worker to continue running. (GDB took a stop-the-world approach, but then later people paid big money to make it support a one-thread-paused model too.)
Ideally, the server should be free to focus on conveying the state of the debuggee in an accurate and robust way, and the front ends should be able to experiment rapidly with different ways of presenting that to the developer. In a sense, the boundary of debugging is already fixed, in that it needs to match what the Chrome protocol expects. I'd be very surprised if it weren't a same-origin related browsing context, though. On Tue, Sep 6, 2016 at 9:58 AM, Nick Fitzgerald <[email protected]> wrote: > I think that each unit of sequential execution should get its own debugger > server (so a (same origin?) related browsing context). Then if we want to > present a unified interface, we can race-ily pause workers (and cross > origin iframes?) and coalesce these things in the UI or via a supervisor > task. > > Basically, nothing really different from Gecko except that we can > /actually/ pause event queues for different contexts and can talk about > related browsing contexts directly instead of via guesswork. > > On Tue, Sep 6, 2016 at 5:40 AM, Till Schneidereit < > [email protected] > > wrote: > > > On Tue, Sep 6, 2016 at 4:35 AM, Boris Zbarsky <[email protected]> wrote: > > > > > On 9/5/16 8:17 AM, Till Schneidereit wrote: > > > > > >> I don't think it makes too much sense to be able to pause completely > > >> independent browsing contexts that can't possibly interact with each > > >> other. > > >> > > > > > > There is no such thing. They can always interact, just async. > > > > > > > That is indeed an important point. While I meant sync interactions, that > > doesn't cover worker threads, so it can't be the whole story. > > _______________________________________________ > > dev-servo mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
