Process local variable and debugging

Tim Rowledge tim at sumeru.stanford.edu
Wed Feb 13 02:51:38 UTC 2002


Well, nobody has offered up any actual code for this problem, so let's
run though a couple of ideas.

The first problem comes down to 'context' or 'Process'; are these
process global variables to be considered to belong to the stack of
contexts currently above the active context, or are they to belong to
the Process? Which Process - how do you work out which process is
attached to the context?

If to the context stack, then we are reasonably safe in scanning up the
stack and finding a place where we can consider it to be the root. Or we
could (ab)use the exception handlers and allow overriding of these
values anywhere in the stack. Or we could have a simpified prim similar
to the exception handler prim that just finds the root context. Things
remain safe almost no matter what we do with #swapSenders: and other fun
stack manipulations, though the effects might be amusing. The drawback
is that scanning the stack is somwhat slower than merely accessing
variables. It should be safe in the debugger though, both practically
and semantically.

For the process, we have only Processor activeProcess as a mechanism for
now. At least, I don't know any good way to reliably get the process
from a context (barring Anthony's changes). When debugging, we could
possibly trap #activeProcess (it looks easiest to me if we give it a
fake primitive, then it can be picked up in ContextPart>
doPrimitive:method:receiver:args:) to return the process being debugged.
What happens if you do a doit in the debugger and really want the actual
active process though?

The second idea was that described by Dave Simmons; swap the values of
the Associations in the literal frames of the affected methods. This
gets past the problem of the wrong activeProcess, but does involve
potential messing around when debugging - the process running the
debugger mustn't change the values that were/are in use by the debuggee.
I'm also still unsure of exactly what one needs to do to implement this
idea for anything but the most trivial case; since we would have to set
the values of any/all Association involved for every process
suspend/resume it seems like it could get expensive for more than a
couple. Maybe the answer is to only have one, and have it be a
dictionary of the rest of the variables of interest?

Anyone else have interesting thoughts?

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- If you stand close enough to him, you can hear the ocean.




More information about the Squeak-dev mailing list