newProcess debugging help

Bert Freudenberg bert at freudenbergs.de
Wed Sep 6 09:01:00 UTC 2006


That's what my first variant allows. It pushes a new process to the 
stack, which becomes the result of the #newProcess send in the original 
process. The second debugger is not opened immediately, but only when 
the new process is resumed from the first debugger.

It would be nice if the second debugger would automatically step into 
the forked block (that's what the doubled #step in the second variant 
does). It is surely possible, but not with a one-liner like this I fear ;)

- Bert -

Ron Teitelbaum schrieb:
> Thanks for responding!  (Sometimes I feel like I'm talking to myself!)  
> 
> I'll have to look at your suggestions more closely.  I like that you were
> interested in opening a second debugger.  It would be nice if when you step
> into a new thread, the new debugger opens up, but the old one processes
> through instead so that it could be continued also.
> 
> Thanks again!!
> 
> Ron Teitelbaum
> 
>> -----Original Message-----
>> From: Bert Freudenberg [mailto:bert at freudenbergs.de]
>> Sent: Tuesday, September 05, 2006 10:12 AM
>> To: Ron at USMedRec.com; The general-purpose Squeak developers list
>> Subject: Re: newProcess debugging help
>>
>> Ron Teitelbaum schrieb:
>>> Hello all,
>>>
>>> Is there a way to know that a method is being simulated in a debugger?
>> I
>>> would like to have two different paths
>>>
>>> thisContext isDebugging ifTrue: [aBlock value]
>>> 	ifFalse: [aBlock newProcess].
>>  >
>>> so that I can debug the new process without having to change the code
>> and
>>> remove the threading.  Or is there a better way to step through code
>> that is
>>> executing in a different thread?  It would be nice if when the debugger
>> hit
>>> a new thread it would simply open up a new debugger on that thread, then
>> you
>>> could keep stepping through either debugger.
>> Actually, when you step into a #newProcess send, you should get a new
>> debugger (see ContextPart>>doPrimitive:method:receiver:args:). Maybe
>> this mechanism could be used to do something more intelligent:
>>
>>    (primitiveIndex = 19) ifTrue:[
>>      meth == (BlockContext>>#newProcess) ifTrue: [
>>        ^self push: [receiver halt: 'New process'; value] newProcess].
>>      ...
>>
>> If you now try to step into #newProcess, a new process is created that
>> raises a Halt when resumed. Alternatively, you could immediately open a
>> Debugger on the new process:
>>
>> (primitiveIndex = 19) ifTrue:[
>>      meth == (BlockContext>>#newProcess) ifTrue: [
>>        | process |
>>        process := receiver newProcess.
>>        process step; step. "step "
>>        process debugWithTitle: 'New process'].
>>        ...
>>
>> Here, you have to be careful not to resume the process in the original
>> debugger.
>>
>> This interception of #newProcess will only work if you step "into" or
>> "through" a send, stepping "over" does not simulate the code but runs it
>> at full speed.
>>
>> Anyway, that's the basic idea. I'm pretty sure you could do a lot more
>> if you grok contexts and processes. To be really useful you would have
>> to intercept waits, too.
>>
>> - Bert -
> 



More information about the Squeak-dev mailing list