On Fri, Jun 2, 2017 at 8:08 AM, Eliot Miranda <[email protected]> wrote:
> 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. > This is what I touching on here.. http://forum.world.st/Accessing-effectiveProcess-from-a-primitive-td4919094.html cheers -ben
