Hi Denis,

On Thu, Jan 7, 2016 at 8:44 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Denis,

On Thu, Jan 7, 2016 at 7:54 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Look at example:

methodA
�� | result |
�� result := false.
�� [result := self methodB] ensure: [result ifTrue: [...]]

methodB
�� result := 1 < 2.
�� ^result

Imagine now that methodB starts execution in context of call inside methodA.
Is it possible to terminate process at point of methodB return (^result)?��
In that case ensure block in methodA will perform wrong logic.

Returns are not suspension points, so no.�� In the Cog and Stack VMs the only suspension points are backward jumps (at the end of while loops) and method activations.�� Note that invocations of methods with primitives (including quick methods, e.g. ^true or ^instVar) are not suspension points, unless their primitives fail, or unless the primitives are suspend, wait et al.��

I forgot to say that block activations are also suspension points.�� In the Cog JIT sufficiently simple methods and sufficiently simple blocks are not necessarily suspension points when converted to machine code. ��the KIT will generate a frameless method (which is not a suspension point) if the block or method contains only #== and #class sends and no jumps and no temporary accesses.�� But this is just an optimization, and it removes suspension points not adds them.��

��

In the interpreter VM (incorrectly IMO) primitive invocation in the context of a perform:, tryPrimitive:, executeMethod: primitive is also a suspension point. ��i.e. /any/ primitive including a quick primitive invoked via primitives 83, 84, 100, 188, 188 & 189, could potentially be a suspension point, in which case the process would be suspended immediately following the send that invoked the primitive.

_,,,^..^,,,_
best,��Eliot

_,,,^..^,,,_

best,��Eliot