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

Eliot Miranda eliot.miranda at gmail.com
Tue Sep 7 17:23:05 UTC 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100907/1bb17426/attachment.htm


More information about the Squeak-dev mailing list