Re: Howto suspend JSD when hitting a breakpoint

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Howto suspend JSD when hitting a breakpoint

timeless-3
On Dec 6, 2:11 pm, "joheks" <[hidden email]> wrote:
> Hi im working with spidermonkey and JSD.
> I have managed to set a breakpoint and get the callback that a
> breakpoint was hit. But i can´t understand how you could suspend the
> engine while waiting for user input. Do you have to launch the
> spidermonkey (and JSD) in a seperate thread and when you signal back to
> the user in the callback method you actually wait for user input.

venkman definitely doesn't use threads (in fact it's patently thread
unsafe - using venkman w/ threads will get your app killed faster than
you can make a peep).

you can still look at it for an example of something that /mostly/
works (in fact the only reason venkman doesn't work is that most of its
callbacks are DOM objects, and dom objects aren't threadsafe, but
fixing that requires rewriting very large portions of venkman :()

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Howto suspend JSD when hitting a breakpoint

John Bandhauer
timeless wrote:

> On Dec 6, 2:11 pm, "joheks" <[hidden email]> wrote:
>> Hi im working with spidermonkey and JSD.
>> I have managed to set a breakpoint and get the callback that a
>> breakpoint was hit. But i can´t understand how you could suspend the
>> engine while waiting for user input. Do you have to launch the
>> spidermonkey (and JSD) in a seperate thread and when you signal back to
>> the user in the callback method you actually wait for user input.
>
> venkman definitely doesn't use threads (in fact it's patently thread
> unsafe - using venkman w/ threads will get your app killed faster than
> you can make a peep).
>
> you can still look at it for an example of something that /mostly/
> works (in fact the only reason venkman doesn't work is that most of its
> callbacks are DOM objects, and dom objects aren't threadsafe, but
> fixing that requires rewriting very large portions of venkman :()
>

A more direct answer to the OP's question is: Venkman spins the UI
thread's event loop in a nested stack frame while the target code sits
on the stack waiting for Venkman to exit the event loop and return from
the hook.

Take a look at debugTrap in venkman-debugger.js. See how it uses
jsdService::EnterNestedEventLoop.

I doubt anyone cares, but... The bulk of JSD was written for Navigator 4
before xpcom existed. In Nav4 the JS engine ran on a dedicated non-UI
thread. The debugger UI was written in Java. It had a layer to manage
the interaction between the JS thread and the bulk of the debugger UI
running in Java on the UI thread.

JSD's xpcom API was added (by rginda) to support Venkman. The fact that
this all runs on the UI thread is IMO a great simplification.

John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger