Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-debug-dev] Debug Event Processing


Further implementation details:

* I believe this function should be placed in the debug core (rather than Java debug)
* The debug core will have its own thread in which to execute runnables. In the Java debug case, events are fired from the JDI event dispatch thread. If one were to use the event firing thread to run a runnable, the debug model would no longer be able to process debug events, which could be undesirable, or even result in a deadlock. The "queued runnable thread" should be created when first required, and should automatically terminate when no debug sessions are active, or when the debug plug-in shuts down.

Darin




Jared Burns <jared-eclipse@xxxxxxxxx>
Sent by: jdt-debug-dev-admin@xxxxxxxxxxx

07/22/2002 05:14 PM
Please respond to jdt-debug-dev

       
        To:        jdt-debug-dev@xxxxxxxxxxx
        cc:        
        Subject:        Re: [jdt-debug-dev] Debug Event Processing


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
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev



Back to the top