Hi Guille,

On Wed, May 31, 2017 at 12:48 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:

On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Thomas,

On May 29, 2017, at 7:41 AM, Ben Coman <btc@openinworld.com> wrote:

On Mon, May 29, 2017 at 9:34 PM, <tdupriez@ens-paris-saclay.fr> wrote:
[...]��

Here is my example code. Beware, running it will freeze the VM.

| program process context debugSession |
�� program := [1+2].
�� process := program newProcess.
�� context := process suspendedContext.
�� debugSession := process newDebugSessionNamed: 'StepIntoForever' startedAt: context.
�� [ true ] whileTrue: [ debugSession stepInto ].

��[...]

In particular, your use of stepInto: will soon step into the process termination code.�� See newProcess.�� You have to stop simulating before you stop the current process by mistake.

��
Yes, I explained yesterday to Thomas that this would end up terminating the UIProcess where the debugger is running on, instead of terminating the process that is being debugged. But, it looks like a bug...

It would make sense to me that "Processor activeContext" yields the debugged context in the simulated code instead of the real active context. And I believe that this change should not break any existing code.

Actually, thinking a bit more about this, similar problems may happen if we try to execute in the debugger Semaphore code in the debugger. So probably, in general terms, the debugger should handle specially all code that messes up with the Process machinery.

Alas is isn't possible to implement this directly in the execution simulation machinery because of things like this:

Context>>runUntilErrorOrReturnFrom:

Context>>jump

Context>>jump uses the simulation machinery to advance execution, so the execution simulation machinery has to simulate exactly. �� Context>>runUntilErrorOrReturnFrom: uses Context>>jump and is used in the exception delivery process.

I expect the process state changing primitives can apply to effectiveProcess.�� So in Context>>doPrimitive:method:receiver:args:see

"Mutex>>primitiveEnterCriticalSection

Mutex>>primitiveTestAndSetOwnershipOfCriticalSection"

(primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue:

[| effective |

effective := Processor activeProcess effectiveProcess.

"active == effective"

value := primitiveIndex = 186

ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective]

ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: effective].

^(self isPrimFailToken: value)

ifTrue: [value]

ifFalse: [self push: value]].

We would have to have similar code for suspend and resume primitives.�� I don't see how this mechanism solves the issues with wait and signal though.�� They need to be handleable as per primitiveEnterCriticalSectionOnBehalfOf: etc.�� We would have to modify the VM and add signalOnBehalfOf: and waitOnBehalfOf:.�� There might be a bug tail here because I fear that the system depends on these being 0 argument primitives to avoid stack growth on signal/wait.

--��

��

Guille Polito

Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

_,,,^..^,,,_

best,��Eliot