[jdt-debug-dev] Conditional breakpoint event handling (or "reduced debug

[Jared Burns <jared-eclipse@xxxxxxxxx>]

I'm sending this to the list because we have a problem whose proposed 
solution would affect debug event sets. As per the proposal, if a conditional 
breakpoint occurs at the same time as another event which causes a thread to 
suspend (a step-end or a non-conditional breakpoint), we will ignore the 
conditional breakpoint. The resulting debug event set will not contain 
conditional breakpoint events. We don't expect this to be a problem; if you 
disagree, please let us know why.

From "Stepping to a line with a conditional breakpoint Bug 13015" 
(http://bugs.eclipse.org/bugs/show_bug.cgi?id=13015):

The debugger currently has a bug whereby if you step to a line that contains 
a conditional breakpoint which evaluates false, the program resumes. 

This happens because we get a step-end and breakpoint-hit event in an event 
set from the VM. Our event dispatcher dispatches these events to listeners as 
appropriate and the listeners vote on whether the thread should be resumed. 
The step listener votes "no" and so does the conditional breakpoint. The 
event dispatcher doesn't resume the thread and then continues dispatching new 
events. Meanwhile, the conditional breakpoint has spawned an asynchronous 
evaluation to decide if it *really* wants to stay suspended. If the 
evaluation comes back false, it resumes the thread. By this time, all voting 
in the event dispatcher is long finished so the thread simply resumes.

Proposed solution:

When the EventDispatcher is iterating over the events in an event set, it will
defer dispatch to conditional breakpoints. Step-end and non-conditional
breakpoints will be handled as usual during the iteration.

When the first loop is done, the dispatcher will examine the current
resume-thread vote. If the vote says to not resume the thread, the dispatcher
will continue as normal, ignoring the deferred conditional breakpoint events. 
If the vote says to resume the thread, the deferred conditional breakpoint 
events will be dispatched and handled as usual.

This solves two problems:
1. We won't have conditional breakpoints resuming threads that should stay 
suspended because of a step or non-conditional breakpoint.
2. We won't have two event sets fired for the same suspension, as would occur
when a step-end and conditional breakpoint that resolved to "true" were hit at
the same time.

- Jared