Hi Guille, On Wed, May 31, 2017 at 12:48 AM, Guillermo Polito < [email protected]> wrote:
> > > On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <[email protected]> > wrote: > >> Hi Thomas, >> >> >> On May 29, 2017, at 7:41 AM, Ben Coman <[email protected]> wrote: >> >> >> >> On Mon, May 29, 2017 at 9:34 PM, <[email protected]> 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* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- _,,,^..^,,,_ best, Eliot
