Hi Norbert,

    [ let me try again.  never try and get code out too early in the
morning ;-) ]

    it is the debugger that needs fixing, not your code !! :-).  The
debugger needs to respect process identity.  Andreas and I (mostly Andreas)
came up with the following changes at Qwaq.  Your message is a good
reminder that I need to add this to Squeak asap.

The idea is for Process to have an additional inst var 'effectiveProcess'
that holds the actual process running code.  For the most part this is
self, but in the debugger we substitute the process being debugged:

*Process methods for accessing*
*effectiveProcess*
"effectiveProcess is a mechanism to allow process-faithful debugging.  The
debugger executes code
 on behalf of processes, so unless some effort is made the identity of
Processor activeProcess is not
 correctly maintained when debugging code.  The debugger uses
evaluate:onBehalfOf: to assign the
 debugged process as the effectiveProcess of the process executing the
code, preserving process
 identity."
^effectiveProcess ifNil: [self]

then the relevant methods in Process and processorScheduler defer to
effectiveProcess, e.g.

*ProcessorScheduler methods for process state change*
*terminateActive*
"Terminate the process that is currently running."

activeProcess effectiveProcess terminate

and the debugging methods use evaluate:onBehalfOf: to install the process
being debugged:

*Process methods for private*
*evaluate: aBlock onBehalfOf: aProcess*
"Evaluate aBlock setting effectiveProcess to aProcess.  Used
 in the execution simulation machinery to ensure that
 Processor activeProcess evaluates correctly when debugging."
| oldEffectiveProcess |
oldEffectiveProcess := effectiveProcess.
effectiveProcess := aProcess.
^aBlock ensure: [effectiveProcess := oldEffectiveProcess]

*Process methods for changing suspended state*
*step*

^Processor activeProcess
evaluate: [suspendedContext := suspendedContext step]
onBehalfOf: self

*stepToCallee*
"Step until top context changes"

Processor activeProcess
evaluate:
[| ctxt |
ctxt := suspendedContext.
[ctxt == suspendedContext] whileTrue: [
suspendedContext := suspendedContext step]]
onBehalfOf: self.
^suspendedContext

etc.  Changes from a Qwaq image attached.

HTH


On Mon, Jun 23, 2014 at 4:50 AM, Norbert Hartl <[email protected]> wrote:

> In my code I'm using a DynamicVariable to request a context object when
> needed. Until now I knew the name DynamicVariable only from seaside. There
> it is called WADynamicVariable and it is an exception. So I blindly assumed
> the pharo DynamicVariable works the same.
> I thought this might be a good optimization not to travel the stack all
> the time but put in the process.
> Now that I am using it I can see the difference. I find it real hard using
> it because I don't know how to debug/step in code. DynamicVariable is a
> process specific variable but as soon as a debugger opens it is very likely
> to be in another process. This makes stepping in method using the
> DynamicVariable impossible. The only way round is to set break points after
> the dynamic lookup and step from there. But this feels just wrong.
> What would be the best way to have DynamicVariable and be able to debug
> anything? Or is there a variant that uses the stack instead of the "active"
> process?
>
> thanks,
>
> Norbert
>
>
>


-- 
best,
Eliot

Attachment: effectiveProcessMethods.st
Description: Binary data

Reply via email to