class ThreadController

The deferred callback is executed when this step controller has completed its work. To a first

approximation, this is when the step is complete.

BUT when a step is complete may not be obvious or well-defined. The user could step over

"MessageLoop::Run()" which might never complete. If you run "until", then hit a breakpoint, and

step from there, the "until" controller will still be pending even though other step operations

have been executed. The user can also type Control-C to clear all the current stepping state

which can clear the operation before it's conceptually complete.

Note that this is different than the callback on InitWithThread().

Registers the thread with the controller. The controller will be owned by the thread (possibly

indirectly) so the pointer will remain valid for the rest of the lifetime of the controller.

The implementation should call SetThread() with the thread.

When the implementation is ready, it will issue the given callback to run the thread. The

callback can be issued reentrantly from inside this function if the controller is ready

or fails synchronously.

If the callback does not specify an error, the thread will be resumed when it is called. If the

callback has an error, it will be reported and the thread will remain stopped.

The callback indicates that the initialization has completed, not that the thread controller

has completed. For controller completion, see the constructor.

Returns how to continue the thread when running this controller. This will be called after

InitWithThread and after every subsequent kContinue response from OnThreadStop to see how the

controller wishes to run.

A thread controller can return a "synthetic stop" from this function which will schedule an

OnThreadStop() call in the future without running the thread. This can be used to adjust the

ambiguous inline stack state (see Stack object) to implement step commands.

GetContinueOp() should not change thread state and controllers should be prepared for only

InitWithThread() followe by OnThreadStop() calls. When thread controllers embed other thread

controllers, the embedding controller may create the nested one and want it to evaluate the

current stop, and this happens without ever continuing.

Notification that the thread has stopped. The return value indicates what the thread should do

in response.

At this call, the stop location will be thread().GetStack()[0]. Thread controllers will only

be called when there is a valid location for the stop, so there is guaranteed to be at least

one stack entry (in constrast to general thread exception observers).

ARGUMENTS

---------

The exception type may be "kNone" if the exception type shouldn't matter to this controller.

Controllers should treak "kNone" as being relevant to themselves. When a controller is used as

a component of another controller, the exception type may have been "consumed" and a nested

controller merely needs to evaluate its opinion of the current location.

The stop type and breakpoint information should be passed to the first thread controller that

handles the stop (this might be a sub controller if a controller is delegating the current

execution to another one). Other controllers that might handle the stop (say, if a second

sub-controller is created when the first one is done) don't care and might get confused by stop

information originally handled by another one. In this second case, "kNone" and an empty

breakpoint list should be sent to OnThreadStop().

RETURN VALUE

------------

If the ThreadController returns |kStop|, its assumed the controller has completed its job and

it will be deleted. |kContinue| doesn't necessarily mean the thread will continue, as there

could be multiple controllers active and any of them can report "stop". When a thread is being

continued, the main controller will get GetContinueOp() called to see what type of continuation

it wants.

Writes the log message prefixed with the thread controller type. Callers should pass constant

strings through here so the Log function takes almost no time if it's disabled: in the future

we may want to make this run-time enable-able

Returns the given frame's function name or a placeholder string if unavailable. Does nothing if

logging is disabled (computing this is non-trivial).

How the frame argument to SetInlineFrameIfAmbiguous() is interpreted.