[Vm-dev] rationale for simulation guard in BlockClosure>>newProcess?

[Andreas Raab]

The simulation guard was introduced to avoid crashing the VM when 
attempt to simulate certain behavior. If such behavior no longer causes 
crashes, it's fine to remove them (be sure to actually step through it 
to see if there's a problem or not).

Cheers,
   - Andreas

On 9/7/2010 10:23 AM, Eliot Miranda wrote:
>
>
>
>
> Hi All,
>
>      the simulation guard in BlockClosure/BlockContext>>newProcess
> (primitive 19) prevents creating processes during debugging which means,
> amongst other things, one can't step into displayingProgress: blocks
> which is /very/ annoying.  What's the rationale?  My first unconsidered
> instinct is that it's OK to crate and schedule processes during
> simulation; one simply shouldn't expect them to be debugged.
>   Alternatively one could offer to open a debugger on the new process
> (perhaps wrap it in some object such that when it receives resume the
> debugger is spawned?), create the process or fail in
> doPrimitive:method:receiver:args:.  What do those in the know, know and
> think?
>
> (SystemNavigation new browseAllSelect: [:m| m primitive = 19])
>
> [BTW, re being able to debug a process when it becomes resumable, it
> would be good to have the VM's resume primitive do some sanity checking,
> e.g. failing if the receiver's context doesn't smell right, or if myList
> is not nil, which would allow using myList to tag a process created
> during debugging.  The Cog VM fails the resume primitive if
> suspendedContext is not a context]
>
> best
> Eliot