Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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

Back to the top