Debugger woes

Doug Way dway at riskmetrics.com
Wed Sep 3 22:44:55 UTC 2003


I was going to move 3.6 to gamma on Monday, but I'm holding off for a 
few days until this discussion comes to some sort of resolution.

Hopefully we will be able to make a smallish 
change/addition/reorganization to provide something "good enough" for 
Croquet to be able to move to 3.6?  We don't want to make a 
large/destabilizing change at this point in 3.6beta (like for example 
Anthony's original context changes for 3.6alpha, which were important, 
but caused lots of side effects for the debugger which had to be fixed).

Anyway, something to keep in mind during the discussion. :-)

- Doug


Anthony Hannan wrote:

>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