Re: [jdt-debug-dev] Debug Event Processing

[Jared Burns <jared-eclipse@xxxxxxxxx>]

Sounds good to me.

- Jared

On Monday 22 July 2002 05:01 pm, you wrote:
> Yes, that is the suggested implementation.
>
> Darin
>
>
>
>
>
> Jared Burns <jared-eclipse@xxxxxxxxx>
> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx
> 07/22/2002 04:41 PM
> Please respond to jdt-debug-dev
>
>
>         To:     jdt-debug-dev@xxxxxxxxxxx
>         cc:
>         Subject:        Re: [jdt-debug-dev] Debug Event Processing
>
> I want to make sure I understand the proposal. Is the following in-line
> with
> your description?
>
> 1. Create the method DebugPlugin#queueEventRunnable(Runnable). This method
>
> adds runnables to a collection.
> 2. Add code to the end of DebugPlugin#fireDebugEventSet(DebugEvent[])
> which
> spawns a thread to execute each runnable in the collection (I don't think
> we
> want to do this inline).
> 3. Interested DebugEventListeners, would add code to their
> handleDebugEvents(DebugEvent[]) methods like:
> DebugPlugin.queueRunnable(new Runnable() {
>   public void run() {
>     getDisplay.asynchExec(...);
>   }
> }
>
> Does that sound about right?
>
> - Jared
>
> On Monday 22 July 2002 04:06 pm, you wrote:
> > Following is a proposal for dealing with the toString() evaluation
>
> problem
>
> > described in a previous post.
> >
> > Summary of proposal: A debug event listener needs to be able to register
>
> a
>
> > Runnable, to be run after the current event dispatch is complete. This
> > allows an event listener to perform an evaluation (or some other
>
> response)
>
> > to a debug event, after event processing is complete.
> >
> > Consider the following scenario:
> >
> > * There are 3 debug event listeners - a debug view, a variables view,
>
> and
>
> > the expression view
> > * A debug event is fired signalling that a step has completed
> >
> > The event processing currently goes like this (in the JDI event dispatch
> > thread)
> > * the debug view registers a runnable (A) with the Display queue to
> > refresh the suspended thread (re-draw stack frames)
> > * the variables view registers a runnable (B)  with the Display queue to
> > refresh and populate the details area
> > * the expression view registers a runnable (C) with the Display queue to
> > refresh and populate the details area
> > * At some point the UI thread runs (A), and stack frames are re-drawn
> > * At some point the UI thread runs (B). Varialbes are updated, and then
>
> an
>
> > asynchronous evaluation (E1) is started in a seperate thread to compute
> > details for the selected variable
> > * At some point the UI thread runs (C). Expressions are updated, and an
> > asychronous evaluation (E2) is started in a sperate thread to compute
> > details for the selected expression
> >
> > The time at which E1 and E2 run, in relation to (C) is undetermined
> > currently. If E1 begins and then (C) attempts to access the thread which
> > is no longer suspended, a problem occurrs. We need to be able to run E1
> > and E2 serially after (C). The AST evalutaion engine implementation
> > guarentees evaluations are run serially (looking at the implementation),
> > so all we really need is to guarentee that E1 and E2 are run after (C).
> > This could be acheived by having a facility to execute a runnable after
> > the current event dispatch is complete (in the event dispatch thread).
> > Then E1 and E2 would work by submitting a Runnable to the new facility,
> > which would in turn submit runnables to the Display queue to perform E1
> > and E2. This would mean that E1 and E2 are queued up as UI runnables,
> > after (A,B,C). The evaluation engine provides serial execution of the
> > evaluations.
> >
> > Pros:
> > * Reasonably simple to implement
> >
> > Cons:
> > * Complex to explain (i.e. must understand debug events, UI (Display)
> > event queue, and evaluation interactions).
> >
> > Issues:
> > * Should the support to run a Runnable after the current event dispatch
>
> be
>
> > Debug platform support, or Java Debug specific support?
> >
> > Comments welcome.
> >
> > Darin
>
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev