[Vm-dev] Re: [Pharo-dev] Interrupting processes question. Can method return be interrupted?

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 7 20:48:24 UTC 2016

Hi Denis,

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

> Hi Denis,
> On Thu, Jan 7, 2016 at 7:54 AM, Denis Kudriashov <dionisiydk at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160107/07bf6852/attachment.htm

More information about the Vm-dev mailing list