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

["Darin Wright" <Darin_Wright@xxxxxxx>]

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

"Darin Wright" <Darin_Wright@xxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 07/17/2002 04:34 PM Please respond to jdt-debug-dev

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

The Java debugger exhibits a known problem with regards to displaying the details or 'toString' of a selected variable or _expression_. The specific scenario is as follows: 

(1) The variables view receives a "suspend event" 
(2) The variables view asks the Java debug presentation for the details for the selected variable 
(3) The Java debug presentation starts an asynchronous evaluation in the thread that just suspened to obtain the 'toString' of an object 
(4) Susequent event listeners are informed of the "suspend event". However, at  this point the thread can actually be running, due to the implicit evaluation calculating the 'toString'. This can cause event listeners to randomly fail when processing events. The failure is not predicatable, as the problem is timing dependent. For example, the debug view may attempt to render the stack frames for a thread, but the thread is running (and has no stack frames). 

The above problem can be generalized: If an event listener changes the state of a debug model, subsequent event listeners are informed of an event which is now out of synch with the debug model. Furthermore, many event listeners are in the UI and perform UI updates. Such listeners often submit async runnables to the Display, which are run at a later time. There is no guarentee that the debug model is in the same state when  a runnable is executed, as when the associated debug event was reported. 

This is a similar problem to workspace modification. That is, when a resource change callback is taking place, the workspace cannot be modified. As well, only one client may modify the workspace at a time (i.e. a client obtains a lock on the workspace in order to modify the workspace). 

Ideally, event processing would occurr as follows: 
(1) All event listeners are informed of an event set 
(2) All UI updating based on the event set is completed (updates are not allowed to change the state of the debug model). 
(3) Any event listeners that need to perform operations on the debug model are run serially (for example there could be multiple views requiring implicit evalautions to be run). 

Discussion/proposals on how such an infrastructure could be implemented are welcome (I'm still working on my proposal). 

Darin