Hi Andrei, Hi Thomas,
Andrei, you are right; they are different and the difference is important.
As you say, suspendedContext is the top (“hot”) context in a process’s context
chain, but interruptedContext is the context which sent the signal message that
eventually raised the exception that invoked the debugger. suspendedContext is
therefore where execution is in the process, but interruptedContext is where
the debugger should show the stack.
Thomas, because the exception system is implemented in Smalltalk the handling
of the initial signal (eg in Object>>#halt), all the way to opening a debugger,
is itself Smalltalk code, and exists as activations from suspendedContext to
interruptedContext. The debugger, with help from the exception system,
carefully hides this processing from the programmer. If it did not we would
have to wade through many activations before we found where the exception
occurred.
When a process is interrupted by control period things are different. Here,
another process handles opening the debugger and indeed suspendedContext and
interruptedContext are the same.
So the difference between suspendedContext and interruptedContext is vital to
the debugger. Without it we would see the inner machinery of the exception
system when errors or exceptions are raised.
HTH
_,,,^..^,,,_ (phone)
> On Nov 30, 2018, at 7:42 AM, Andrei Chis <[email protected]> wrote:
>
> Hi,
>
> From what I remember they are not always redundant, but I'm not 100% sure
> they are both needed.
>
> `suspendedContext` from Process is always the top context of a process. After
> execution actions like Step Into, Step Over, Step Through it will be the same
> as interruptedContext in the debugger.
>
> They will be different when opening the debugger as a result of an exception.
> Exception>>#debug triggers the workflow for opening a debugger. This uses
> `self signalerContext` as the context that is being debugged. This is the
> context where the exception was raised and this will be put in the
> interruptedContext. As this point the execution of the current process is not
> over and it will continue up to
> `MorphicUIManager>>#debugProcess:context:label:fullView:notification: ` where
> the current process is suspended. At that point the two will be different, as
> suspendedContext will be the context of the method
> MorphicUIManager>>#debugProcess:context:label:fullView:notification: and the
> interruptedContext the context that triggered the exception.
>
> But it might be that they are not both needed. One possible option might be
> to force the process to step to the context that raised the exception when
> the debugger is created. For example in DebugSession>>process:context:.
> Apart from when opening the debugger I do not know if there is another
> situation where those two can diverge.
>
> Cheers,
> Andrei
>
>> On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez
>> <[email protected]> wrote:
>> Hello,
>>
>>
>> Instances of DebugSession have an "interruptedContext" and an
>> "interruptedProcess" instance variable.
>>
>> Instances of Process have a "suspendedContext" instance variable.
>>
>> Does someone know if there is a relation between the interruptedContext of a
>> DebugSession and the suspendedContext of its interruptedProcess? At first
>> glance it seems like these two variables are redundant and store the same
>> Context.
>>
>> Thomas Dupriez
