REference Debugger - Task Design

Similarly to many other interactive applications, one of the goals of a debugger is to be responsive to user requests, regardless of the internal state of the application.
This is not always easy to achieve without careful consideration during the design of the debugger.
Let's consider the different approaches that can be used.
Responsiveness requires that the debugger be ready to reply to external events with a meaningful response within a given amount of time. Current debuggers don't always realize this goal because they use one of the two following approaches:

they are single-threaded, thus using as much time as they need to compute a value, and relying on the operating system's signaling mechanism to interrupt the current operation (e.g. gdb). The main problem with this approach is that it's very difficult to keep the state of the debugger consistent when an interrupt is received from the user. One cannot know how many data structures are stable before interrupting the current operation and jumping to receive the next command. The use of global variables increases the difficulty of understanding and maintaining the code.
They use separate threads extensively, with different threads dedicated to different operations (such as reading registers, disassembling code, computing expressions etc.) The main problem with this approach is that it's difficult to coordinate the different threads when they need to interact among each other (for example an expression may need to read target memory at the same time as the disassembler needs to read the opcodes of the target program). Thread synchronization requires extensive use of semaphores and serialized access to shared resources such as symbol table and target communication.

A possible different approach is the very limited use of 2 separate threads to monitor the input/output channels (from/to the user interface and from/to the target). However, the main computational code of the debugger is mostly run by the main (default) thread and is kept sequential, operating on task objects that can switch between different states:

Ready	A task is in this state when it has all information it needs to perform some computation. This could be because the command has just been received from the user, or because all needed data has been received from the target. The main thread of the debugger will switch one task from the ready state to the running state, and will start executing the associated computation.
Running	Only one task is running at any given time. It stays in the running state until it either completes its computation, or it needs to wait for data that is not currently available. Only the main thread of the debugger executes running tasks. Because there is only one thread, there is no synchronization problem. The state of the debugger is guaranteed to be consistent whenever a task changes state.
Waiting	A running task can enter the waiting state when it requires data, usually from the target. This could be reading a memory area or registers or waiting for the target to stop execution. When data is received by one of the I/O threads, the data is stored in the waiting task’s object and the state is switched to ready. The task will continue its computation when the main thread of the debugger will consider this task again. Note that a waiting task can also be interrupted by the I/O thread that is listening to the user’s input. In this case the I/O thread simply sets the state of the task to interrupted and leave to the main thread of the debugger to release the interrupted task.
Complete	Once a running task has finished its computation, or it has been marked as interrupted, the main thread of the debugger will return the result to the user and destroy the task.

The following diagram shows the lifetime of a task: