Debugger woes

Anthony Hannan ajh18 at cornell.edu
Wed Sep 3 03:31:35 UTC 2003


Hi Andreas & Terry,

>> I wanted to execute the unwind blocks in the context of the 
>> terminating process and not the calling process. Meaning if
>> an unwind block raises an exception, an exception handler in
>> the terminating process will handle it and not one in the
>> calling process.

> Ah, I see. Is this the "standard" semantics?

I don't know. But its seems correct since the programmer writes the
ensure: unwind block in the same context as the protected block, and the
protected block is assumed to be executed within the handlers of the
current thread.

> One more question because I'm sure you must have thought
> about it: Do you have any idea about an idiom that can be used for
> retrieving the active process in the context of a debug session?

Yes, "thisContext process".  This is also better for a muli-threaded
environment.  Its semantics is: give me the process that is executing
this context.  It's not: give me the supposed only process running.  To
implement it, the bottom context could point to owning process.  Or,
while Squeak remains single threaded, ContextPart>>process could be a
simulation-guard primitive that always fails and returns "Processor
activeProcess".  When simulating the simulator can catch this guard
primitive and return the process being simulated.

For your other problem of knowing when a process is being debugged or
not, I would generalize your debugger field to a processor field. 
processor would point to the process or Processor that owns it (running
it).  I would even combine myList and processor into a single field.  So
if it is:
	nil -> no processor, suspended;
	Processor -> running;
	queue -> ready to run;
	Semaphore -> waiting for signal;
	a Process -> simulating.
The processor field would also indicate who has a lock on it.  Again, in
a multi-processor environment this processor field would be necessary
(if we didn't want to search all processors to find out who is running a
process).

Cheers,
Anthony



More information about the Squeak-dev mailing list